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Welcome 


Introduction 

Audience 

This course is designed for Sales or System Engineers, Technical Support 
Specialists, and Installation Specialists with a working knowledge of voice and 
data who need the fundamentals of Voice over Internet Protocol (VoIP) 
technologies, including: 

• Voice packetization 

• Packet telephony design issues 

• Traffic convergence issues 

• VoIP standardization and protocols 

• Network assessment 
Background 

This course was designed to to help participants prepare to take the Nortel 
Networks 801 VoIP Technology Exam (Number: 921-801). 
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Objective 

After completing this course, you will be able to: 

• Describe how to packetize voice using voice packet analysis, compression 
standards. Real Time Protocol (RTP), and User Datagram Protocol (UDP) 

• Explain and differentiate between the major components of Voice over 
Internet Protocol (VoIP) 

• Define voice quality on a data network, including the performance of 
speech CODECs, delay, echo impairment and control, and packet loss 

• Given required voice CODEC, voice payload, and link speed, calculate the 
bandwidth requirements for VoIP network engineering 

• Describe the common models for voice quality, including E-Model G. 107 
and Mean Opinion Score (MOS) 

• Define methods available for implementing QoS including Resource 
ReSerVation Protocol (IS/RSVP) Approach, Differentiated Services 
(DiffServ) Approach, and Ethernet 802 standards 

• Identify the challenges of low speed Wide Area Network (WAN) 
connections focusing on serialization delay and Maximum Transmission 
Unit (MTU) 

• Define the network infrastructure, including the LAN/WAN environment 
and Security issues 

• Describe the components of the H.323 standard, including the terminal, 
gateway, gatekeeper, and Multipoint Control Unit (MCU) 

• Identify the Session Initiation Protocol (SIP) objectives and protocol 

• Explain the differences between the SIP and H.323 standards 

• Given sample network assessment scenarios, determine the network 
assessment steps and tools for customer network improvements 
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Introduction 

In the area of communications, convergence refers to the act of bringing voice 
and data services together to form a united system with common cabling, 
equipment, and management. 

On a converged network, voice traffic is transported over the IP network, 
rather than the traditional Public Switched Telephony Network (PSTN). Using 
IP, calls travel as packets of data on shared lines at a much faster rate and 
utilize less equipment, while avoiding PSTN charge. 

This lesson reviews some communication fundamentals. For additional 
information about these concepts, see the Voice Fundamentals Reference 
Guide, which is packaged with your course materials. 




Notes 



Issue 2.0 January 6, 2003 


How it Works 






Objectives 

Given this module and the instructor’s presentation, you will be able to 
communicate about communication fundamentals, such as: 

• Analog-to-Digital Conversion 

• Pulse Code Modulation 

• Circuit Switching 

• Packet Switching 

• Time Division Multiplexing 

• T-l Connections 

• Integrated Services Digital Network 

• Frame Relay 

• Asynchronous Transfer Mode 

• Internet Protocol Network 

• How VoIP Works 

• Signaling System 7 

• Synchronous Optical Network 

• Network Performance 
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Analog-to-Digital Conversion 

As information is presented in analog format, conversion to digital occurs at 
various points during transmission through the use of a CODEC (coder/ 
decoder), which can be located in the telephone instrument, the Private Branch 
Exchange (PBX), or the Central Office (CO) equipment. 

When the digital signal arrives at its destination, it is then converted back to 
analog (through a CODEC) for the user to understand. 

Figure 1: Analog-to-Digital Conversion 
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Pulse Code Modulation 


During the analog to digital conversion, an analog signal undergoes a series of 
steps. 

Sampling 

Pulse Code Modulation (PCM) is the process used for sampling. PCM assigns 
an 8-bit binary code (1 or 0) to a specific amplitude of a signal. Sounds are 
sampled at eight thousand samples per second. The sampling rate must be at 
least twice the maximum frequency of the signal being sampled. 


Figure 2: Sampling 
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Quantization 

Once sampling has occurred, the “snapshot” is quantized and assigned a 
number. During quantization, companding can occur when a voice is too loud 
or too soft. Companding allows a soft signal to be measured with the same 
degree of accuracy as the loud signal. 


Figure 3: Quantization 
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Coding 

Each quantized signal is coded, translated into a set of bits, and transmitted 
across the network. 


Figure 4: Coding 


• Translated into a 
set of bits 

• Transmitted across 
the network 



Because these separate “snapshots” are transmitted so closely together, these 
“snapshots” can run together and create the effect of continuous sound, the 
way a movie’s many frames of film create the illusion of motion 
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Circuit Switching 

A circuit-switched network establishes a dedicated circuit between two 
locations during the entire call setup, until disconnect occurs. Information, 
including silent pauses, is transmitted in a continuous stream. A phone 
connection is generally a circuit-switched network. If information is sensitive 
to delay, such as voice and video applications, circuit-switching is best. 

However, it can be quite expensive, since equipment is dedicated solely for a 
particular call. 

The figure below shows how circuit switching provides dedicated connections 
for the duration of each call. 


Figure 5: Circuit Switching 
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Packet Switching 

Data packets of various sizes are routed and relayed in a packet-switched 
network. Each data packet is transmitted separately over individual circuits and 
reconverted into data at the destination. Each circuit is in use only for 
transmission of data packets, and then the circuit is released. If a pause or 
silence occurs during transmission, circuits are not used. When data packets 
begin transmitting again, another circuit relays the data. At the destination, all 
packets with similar headers are grouped together, organized, and delivered. A 
Frame Relay WAN is a packet-switched network, since this type of traffic can 
withstand delays and jitter and can transmit bursts of data. 

The figure below shows how packet switching sends information over the 
same path. 

Figure 6: Packet Switching 
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Time Division Multiplexing 

Time Division Multiplexing (TDM) is a common transmission path shared by 
a number of channels on a recurring basis, interleaving data onto DS-0 
channels. 

TDM supports awide variety of services and technologies, such as video, data, 
Frame Relay, LAN/WAN, ISDN, and ATM. 

Figure 7: Time Division Multiplexing 



Input 

channels 


Composite 

channel 




Issue 2.0 January 6, 2003 


How it Works 










T-1 Connections 


A T-1 provides up to 24 channels of service between two switches, or a switch 
and a CO, over four pair of wires. Before the T-1,24 conversations required 24 
separate pairs of wire. Those 24 wires are now the size of a regular telephone 
cord. A T-1 circuit increases a telecommunications network backbone without 
proportionally increasing the amount of wiring and equipment. 

T-1 services are digital, with information configured as Is and Os. This 
configuration provides a cleaner transmission and minimizes noise. When a 
signal degenerates, regenerative repeaters replicate the original digital 
transmission. 

T-1 circuits require synchronized transmission, meaning the originating switch 
and the terminating switch are clocked together, with the primary site 
providing the master clock. Timing bits are encoded and sent into the 
information stream for T-1 circuits. This “bit-robbed signaling” leaves all 24 
channels available for transmission. Voice services do not suffer significant 
degradation from the “bit-robbed signaling;” however, data transmission 
occurs at 56K to allow extra room for signaling. 

T-1 can transmit at rates of up to 1.544 Mbps (64 Kbps x 24 channels). T-1 

services are also available as fractional T-1, allowing customers to purchase 
only a required number of DS-0 channels. 
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Integrated Services Digital Network 

Integrated Services Digital Network (ISDN) provides PBX-like services 
throughout a customer’s network by delivering a common signaling 
arrangement and advanced features over different vendors’ equipment. 


Figure 9: Integrated Services Digital Network 



Primary characteristics of an ISDN network are: 

• Integrates voice, data, and video services 

• Has a digital end-to-end connection that provides high transmission quality 

• Has improved and expanded services because of B- and D-channel data 
rates 

• Is more efficient and productive 

• Offers advances in device connectivity 
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Two popular ISDN services are: 

• Basic Rate Interface (BRI) 

• Primary Rate Interface (PRI) 

Basic Rate Interface 

BRI integrates voice and data requirements, primarily for home office 
environments, using existing copper wire. 

BRI provides up to 128 Kbps transmission capability with the ability to have 
simultaneous multiple devices active over two B+D channels. BRI allows a 
user to be on the Internet while receiving a fax transmission, since neither 
device uses the entire bandwidth. 


Figure 10: Basic Rate Interface 
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Primary Rate interface 

PRI is designed for corporate networks requiring T-l and integrated voice and 
data capability. 

PRI provides up to 1.54 Mbps transmission capability through 23 B+D 
channels while enhancing signaling and transmission capabilities. 


Figure 11: Primary Rate Interface 
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Frame Relay 

Originally defined for use over ISDN, Frame Relay (FR) is a fast packet¬ 
switching technology for transporting data in both private and public networks. 
FR provides data speeds between 56 Kbps and 45 Mbps. It offers greater 
efficiencies and speed of operation, though no error protection in transporting 
data is available. If frames of data are corrupted while transported, they are 
discarded. It is the responsibility of the end devices to identify data loss and 
attempt to initiate recovery by retransmitting the frame of data. 

FR is a connection-oriented protocol. A communications path must be 
established on a network between a source and destination before data frames 
can be sent. Bandwidth on an FR link is used only when traffic is sent. If no 
traffic is being sent, the bandwidth on the link is potentially available for use. 

FR supports Permanent Virtual Circuits (PVC) and Switched Virtual Circuits 
(SVC). PVCs are generally “nailed-up” circuits. Once established, they are 
always available for use. The call destination never varies. SVCs are 
established when a call is made and last only for the duration of the data 
transfer. FR also allows multiple Virtual Circuits (VC) data to be transmitted 
on the same physical link. 
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Figure 12: Frame Relay 
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Asynchronous Transfer Mode 


Asynchronous Transfer Mode (ATM) is a combination of circuit- and packet¬ 
switching technology using high speed transmission, high bandwidth and low 
delay techniques. 

ATM sends data only when needed. It requires that network connections are in 
place before transmission can occur. 

ATM utilizes fixed-length, 53-byte packets, called cells, for transporting traffic 
over the network. ATM also balances shorter cells for delay-sensitive traffic, 
such as voice and video, and longer cells for delay-tolerant traffic, such as data. 


Figure 13: Asynchronous Transfer Mode 
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Internet Protocol Network 

The Internet Protocol (IP) is a highly flexible, scalable protocol that transmits 
information across any network. 

Figure 14: Internet Protocol Network 


• Most flexible networking protocol in use today for 
telephony solutions in Wide Area Networks (WAN), 
Local Area Networks (LAN), and applications 

• Networks are highly scalable 

• Transmits data over a wide area network 

• Supports the most widely used network operating 
systems 

• Is fault tolerant for data and voice packets 
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There are four components to IP Telephony: 

VoIP Gateways: End-points that connect the PSTN and the IP network- 

responsible for CODEC transformation to convert voice to IP packetization 
tor transport over an IP network 

• Gatekeeper: Emulates the traditional telephony network for signaling and 
call management reporting capability 

IP Terminals: Telephony end-points that connect directly to the IP 
network 

• Telephony Applications: Enable IP to offer feature-rich services in the 
traditional PBX environment 
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Signaling System 7 

Signaling System 7 (SS7) is the backbone of the current communications 
network. SS7 utilizes digital signaling in a circuit-switched network with a 
separate packet network to set up calls, which frees up voice and data trunks to 
carry their optimal amount of traffic. 

SS7 is considered a smart network because it sets up and tears down calls and 
also supports Advanced Intelligent Network (AIN), where a user dials a 
national telephone number and the call is routed to the closest branch location. 

S7 uses out-of-band signaling, or signaling is transmitted by a facility separate 
from the one carrying traffic. Calls are set up faster and sophisticated service 
options, such as 800 number service, CLASS features and calling card 
verification, are available. SS7 enhances ISDN capability, which allows ISDN 
networking across an entire network. 
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Figure 16: Signaling System 7 
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Synchronous Optical Network 

Synchronous Optical Network (SONET) provides a design standard for 
synchronous data transmission on optical media to allow the interworking of 
products from different vendors. Used strictly on fiber optic networks, SONET 
divides bit streams into frames of light pulses, which enables the delivery of 
transmissions in the gigabit range. 

The Synchronous Transport Signal (STS) is the basic electrical signal 
transmission rate and has a speed of 51.84 Mbps. STS is converted to Optical 
Carrier (OC-1), the basic optical transmission rate. The Synchronous Transport 
Signal Level 1 (STS-1) has the capacity of 672 voice channels or 28 T-Is, with 
24 voice channels. 

SONET provides performance measurement at every point in the network by 
immediately detecting performance degradation and allowing maintenance 
troubleshooting to be easily accomplished. SONET can be deployed point-to- 
point; however, it is typically laid out in a dual-ring topology, with redundant 
fiber optic paths. Dual-ring topology causes rapid ring switching to occur in 
the event of fiber or equipment failures, which drastically improves the 
survivability of the network. 
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Network Performance 


In the world of voice communications, the goal is to provide 99.999% 
reliability. This high level of reliability requires constant performance 
monitoring and error checking by both access and network equipment. Factors 
such as jitter, delay, distortion, and echo can immediately denigrate network 
performance. 

In the lessons that follow, you will learn about the methods that you can use to 
implement Quality of Service and reliability. 


Figure 18: Network Performance 


• Goal is to provide 99.999% on-line reliability, cornerstone of circuit¬ 
switching network 

• Requires constant performance monitoring and error checking 

• Factors which can adversely affect network performance 

result is jitter pops and clicks (variable delay only) 

- Delay: End result in voice transmission is echo; in data transmission end 
result is distortion of data 

- Distortion: Direct result of compressing voice at a rate of less than 64 
Kbps 

- Echo: Result of several factions such as strength of the speech 
returned, Round-trip Delay (RTD) and Echo Return Loss (ERL) 
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Summary 

In lesson, you reviewed communication fundamentals, such as: 

• Analog-to-Digital Conversion 

• Pulse Code Modulation 

• Circuit Switching 

• Packet Switching 

• Time Division Multiplexing 

• T-l Connections 

• Integrated Services Digital Network 

• Frame Relay 

• Asynchronous Transfer Mode 

• Internet Protocol Network 

• How VoIP Works 

• Signaling System 7 

• Synchronous Optical Network 

• Network Performance 
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Introduction 

Convergence of the telephone network and the Internet is driving the use of 
packet-based transmission for telecommunications networks. Integration of 
voice and data onto a single network offers significantly improved efficiency 
for both private and public network operators. Data is carried most efficiently 
on packet networks. 

Because data has overtaken voice as the major type of telecom traffic, and data 
traffic volume continues to grow faster than voice traffic volume, it is not 
surprising that the integrated network uses packet-based transmission. Packet- 
based transmission of digital voice is a logical step, but it has some important 
implications for voice quality: 

• Network design, such as packet sizes, packet header overhead, and the 
sizes of queues and buffers, was chosen for optimal efficiency of data 
transfer. 

• Access links, which are dedicated to voice in switched-circuit networks, 
can be shared between voice and data in the packet environment. 
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Objectives 

Given this module and the instructor's presentation, you will be able to: 

• Apply knowledge of how voice is sampled and converted into IP packets to 
calculate overhead 

• Compare and contrast Voice over IP packet-switching models 

• Calculate bandwidth for different compression standards based upon voice 
samples in milliseconds (ms) 

• Apply knowledge of the attributes of Real-Time Protocol (RTP) to identify 
why it is ideal for handling packetized voice in an IP telephony 
environment 

• Compare the unique attributes of User Datagram Protocol (UDP) versus 
Transmission Control Protocol (TCP) 
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Voice Packetization 

CODECs 

For an analog (pulse) signal to travel across a digital network, it must first be 
converted into a digital (number) format. A CODEC (or coder and decoder) is 
a device that applies algorithms, or rules, to perform this conversion. 


Sample Rate 

The sample rate is the number of samples of a sound that are taken per second 
to represent the signal digitally. To accurately convert an analog signal into a 
digital signal, the sample rate must be at least twice the highest frequency of 
the signal. Therefore, an analog signal is sampled at a rate of 8 kHz per second, 
or 8000 times per second. 


Figure 1: Analog-to-Digital Conversion 
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CODEC Selection 


Selecting the appropriate speech CODEC is essential. CODEC performance 
includes the baseline quality (that is, without impairments) and the 
performance with impairments present, such as background noise and lost or 
late packets. 

The table below shows some CODECs that are used for voice traffic. 
Bandwidth requirements are estimates. 


Table 1: CODECs Used for Voice Traffic 


CODEC 

Description 

Use 

G.711 

64 Kbps PCM 1 

Intended for high bandwidth connections 

Delivers optimal voice quality (toll) but requires 
the most bandwidth 

CODEC of choice when bandwidth is not an 
issue 

G.729A/B 

8 Kbps CS-ACELP 2 

Intended for low bandwidth connections 

Requires less bandwidth than G.711 

Delivers near toll quality voice 

G.726 

16, 24, 32, 40 Kbps ADPCM 3 

Intended for low bandwidth connections 

Requires less bandwidth than G.729 at the 
sacrifice of voice quality 

G.723.1 

6.3 Kbps MPMLQ 4 

5.38 Kbps CS-ACELP 2 

Intended for low bandwidth 

Provides most voice channels at the sacrifice of 
voice quality 


1 Pulse Code Modulation (benchmark for voice communications) 
Conjugate Structure-Algebraic Code Excited Linear Prediction 

■7 

Adaptive Differential Pulse Code Modulation 
4 Multi-Pulse-Maximum Likelihood Quantization 
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Voice Packet 

The voice information is divided into packets, also known as datagrams. Each 
packet is transmitted individually across the packet-switched network, often 
following different routes to the destination. Once all the packets forming a 
message arrive at the destination, they are recompiled into the original 
message. 

There are two main parts of the voice packet: 

• Header: Contains control information necessary to deliver the packet 

• Payload: Contains the actual message 


Figure 2: Voice Packet 
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How Overhead Impacts Packet Size 

Packet size is not a significant concern to traditional data (non-voice). For 
voice communications, however, packet size is an important consideration. As 
a result, for bandwidth puiposes, you must factor in the bandwidth associated 
with the overhead. 


Figure 3: How Overhead Impacts Packet Size 
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Comparing Packet-Switching Models 

Voice over Internet Protocol (VoIP), Voice over Frame Relay (VoFR), and 
Voice over Asynchronous Transfer Mode (VoATM) are the three common 
types of packet-switching models for voice transmissions. 

Because the VoIP model uses public networks, additional protocols are 
required to help ensure that packets get delivered in a timely manner. Some of 
these include User Datagram Protocol (UDP), Real-Time Protocol (RTP) and 
Real-Time Control Protocol (RTCP). See the section titled “Transport and 
Session Layer Internet Protocols,’’ later in this lesson, for additional 
information. 

Voice over Internet Protocol 

The VoIP model transmits data over the LAN and WAN using the Internet 
Protocol (IP). IP is a connectionless Layer 3 Network Layer protocol, with no 
continuing connection between the end points. 

IP does not make any assumptions of the underlying Layer 2 protocols. 
Underlying Layer 2 protocols can include: Ethernet, ATM, PPP, Frame Relay, 
and Wireless protocols. 

Note: The term “Layer” refers to seven communication layers of the Open 
Systems Interconnection, or OSI, model, which standardizes concepts and 
facilitates understanding of the data communication architectures. See the 

Resources’ section of this guide for additional information about the OSI 
Model. 


Voice over Internet Protocol Packet 

Each VoIP packet is treated as an independent unit of data. Each computer, or 
host, has at least one IP address that uniquely identifies it from all other 
computers on the Internet. A VoIP packet contains both the sender's Internet 
address and the receiver's address. 
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Voice over Frame Relay 

Frame Relay (FR) is a high-speed, packet switching Layer 2 WAN protocol. 
FR transmits data in variable-size units called frames over a permanent virtual 
circuit (PVC) that connects distant locations. 

Frame Relay Frame 

There are six bytes of overhead per frame. This small amount of overhead 
makes FR an attractive choice for communications. The address field can 
range from two to four bytes in length. The header can be adjusted for large 
networks that require additional addresses. 

Voice over Asynchronous Transfer Mode 

Asynchronous Transfer Mode (ATM) is a Layer 2 LAN and WAN protocol. 
ATM transmits data in fixed-size units called cells, which are 53 bytes in size. 
During the transmission, ATM creates a fixed channel, or route, between two 
points. This makes it easier to track and bill usage across an ATM network, but 
makes it less adaptable to sudden surges in network traffic. 

ATM offers no guarantee of prioritization, unless the customer has purchased a 
Constant Bit Rate (CBR) service. The CBR provides a dedicated channel with 
a fixed bandwidth, based on the needs of the application. 

Voice over Asynchronous Transfer Mode Cell 

ATM uses a fixed-length packet, or cell, for transport. The ATM cell has a 5- 
byte header and a 48-byte payload (53 bytes total). ATM also has additional 
overhead of up to 15 percent for header information associated with VoIP 
transmissions. This impacts how the frame is segmented and the CODEC used. 
There is no trailer for this type of cell, because there is no error checking 
procedure. However, the header includes an error checking mechanism to 
ensure delivery to the correct destination. 
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Calculating Bandwidth for Different Compression 
Standards 

The bandwidth required is directly related to the voice sample size and speech 
CODEC used. Generally, the smaller the voice sample, the greater the number 
of packets needed. / 

To calculate the approximate bandwidth for different compression standards, 
use the following formula: 


4^ 

(Bytes of Voice Payload + IP header) 
x IP packets generated per second of voice 
x 8 bits per byte 


Table 2: Calculating Bandwidth for Different Compression Standards 


CODEC 

Voice Sample 
Size 

IP Packets 
Generated for 

1 Second of 
Voice 

The Math 

IP Bytes 
Required 
for 1 Second 
of Voice 

Effective 

Bandwidth 

G.711 

5 ms = 40 bytes 

Sxr 

200 

Sao/4o 

(40 + 40) x 200 = 

16,000 

X 8 

128 Kbps - MK. 

G.711 

10 ms = 80 bytes 

Sajo 

100 

Sooo/so 

(80 + 40) x 100 = 

12,000 


96 Kbps 6 k|k • 

G.711 

20 ms = 160 bytes 

«ao 

50 

Uco/uo 

(160 + 40) x 50 = 

10,000 

X 8 

80 Kbps - 6414 - 

G.729A/B 

5 ms = 5 bytes 

i y r 

200 

IdCo/s 

(5 + 40) x 200 = 

9,000 

x 8 

72 Kbps - EK c 

G.729A/B 

10 ms = 10 bytes 

ItOO 

100 

loco/io 

(10 + 40) x 100 = 

5,000 

x € 

40 Kbps - % (4 r 

G.729A/B 

20 ms = 20 bytes 
_ 

50 

locof 20 

(20 + 40) x 50 = 

3,000 

Kg 

24 Kbps - 8 \C— 


3^ ^ " 


3 " 2 - 
< K 

P3-2.K 


~ 40 
S y/ ~ S' 


• •••••• 
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Transport and Session Layer Internet Protocols 

Earlier you learned how the CODEC selection and type of VoIP packet¬ 
switching model impact voice transmissions. This section briefly describes 
some Layer 4 and Layer 5 protocols that can be used to implement VoIP 
performance. 

Transmission Control Protocol 

TCP is highly reliable and connection-oriented Layer 4 protocol. TCP provides 
flow control and acknowledgements of traffic, as well as the ability to 
retransmit data, as necessary. Because of these characteristics, TCP is best 
suited for situations when the integrity of the data is more important than the 
end-to-end transmission time. TCP is not recommended for real-time traffic 
because its features, and its slow start, introduce delay that can jeopardize 
voice QoS. 

Real-Time Protocol —^ L AIBSL S 

RTP is well-suited for time-sensitive applications, such as real-time voice, fax, 
and video. RTP is intended as a framework, not a separate layer. Because of 
this, it works well with RTCP and UDP. Some major components of RTP are: 

• RTP Timeclock: Autonomous clock source that determines how many 
clock ticks have occurred 

• RTP Timestamp: Counter value that shows when the packet was created; 
supports silence suppression and jitter calculation 

• Synchronization Source (SSRC): Unique, randomly generated identifier 
that the RTP client uses to identify the RTP session; enables you to tell 
which parties are talking and which parties are silent 

• Contributing sourCe (CSRC): Identifier list following the fixed RTP 
packet header; preserves the identity of the original source 

• Payload Identification: Traffic identification; for example, G.729. 

• Sequence ID: Part of header information 

• Feedback on Jitter: Feedback on jitter for possible adjustment to buffer 
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Q Real-Time Control Protocol 

Real-Time Control Protocol (RTCP) augments RTP. RTCP is designed to 
monitor the quality of service and to convey information about the participants 
in a real-time session. Because RTP runs over UDP, neither end really knows if 
the RTP packets are actually delivered. RTCP solves this problem by providing 
feedback in the form of RTCP QoS reports to the sending party. RTCP also 
provides information about the sender, such as the sender’s name and 
telephone number. 

Interaction between Real-Time Protocol and Real-Time Control Protocol 

RTP provides an end-to-end delivery service for real-time traffic. The figure 
below shows the interaction between RTP and RTCP: 

• RTP carries the data that contains the real-time properties. 

• RTCP monitors the QoS and generates reports about the participants in the 
ongoing session 


Figure 4: Interaction between RTP and RTCP 



f User Datagram Protocol 

UDP is a connectionless protocol that runs on top of IP networks. Because 
UDP lacks many of the features of TCP that introduce delay, such as flow 
control and error recovery, UDP is well-suited to voice traffic. 




Notes 
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Relationship between User Datagram Protocol Packet and 
Real-Time Protocol Header 


The UDP packet does not supply sequence numbers, timestamps, audio source 
identification, CODEC type, and other information important to the delivery of 
real-time information. Because of this, another header, such as the RTP header, 
is required to supply the missing information. The figure below shows how the 
UDP packet and RTP header work together. 


Figure 5: User Datagram Protocol Packet and Real-Time Protocol Header 
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Major Components of Voice over Internet Protocol 

To deploy VoIP, it is necessary to add hardware to support both VoIP 
communications and the new product offerings introduced with VoIP, such as 
open (as opposed to proprietary) IP terminals and unified messaging (voice, 
fax, data, multimedia). 

Some major components that comprise the VoIP model are: 

• Call Servers: Provide call processing for client devices, as well as proxy 
interworking with intelligent terminals and devices 

• Call Signaling Servers: Include an industry-standard Central Processing 
Unit (CPU) to drive the signaling for IP terminals and other IP devices 

• H.323 Gateways: Provide access to Public Switched Telephony Networks 
(PSTNs) and analog devices through a locally routed, direct IP media path 

• Media Gateways: Increase the system capacity to support additional 
trunks, analog and digital telephones, and IP terminals 

• Gatekeepers: Provide address translation, admissions control, and 
bandwidth control 

• IP Terminals and Clients: Connect directly to the LAN through the 
Ethernet connection to bring voice and data communications to the end 
user; an IP telephony server completes the call processing 

• IP Network: Provides the universal communication language and 
foundation to allow dissimilar networks and equipment from a variety of 
vendors to interconnect 

Detailed information about the technologies and protocols that drive these 
devices is located in the “Voice over Internet Protocol Standardization and 
Signaling Protocols” lesson, later in this course. 

Note: H.323 is a packet-based signaling standard that provides a foundation 
for audio, video, and data communications across IP-based networks, 
including the Internet. 
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Figure 6: Major Components of Voice over Internet Protocol 
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Practice 

Answer the following questions. 

1. A customer requires the least amount of bandwidth usage and is not 
concerned with voice quality. Which CODEC would you recommend? 

a. G.711 

b. G.729A 

c. G.723.1 

d. G.726 


2. A customer requires the best balance of quality audio and bandwidth 
savings. Which CODEC would you recommend? 

a. G.711 

b. G.729A 

c. G.723.1 

d. G.727 

3. At what rate is an analog signal sampled using a G.711 CODEC? 

a. 2 kHz 

b. 3 kHz 

c. 4 kHz 

d. 8 kHz 
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4. What are the two main parts of a voice packet? 

a. Header and Payload 

b. Leader and Header 

c. Footer and Load 

d. Leader and Message 

5. On which layer of the OSI model does IP reside? 




OtL^ 

)r'"a ^ 


a. Layer 1 

b. Layer 2 
(Cj Layer3 

d. Layer 5 

6 . Which Layer 2 protocol transmits data at a fixed size unit called a cell? 


•! 


a. PPP 

b. ATM 


c. PPTP 

d. CBR 


15 - UPO1US A i 

^ -aw W*-* 

, pS= 100oms 0V °-Up3c^r UoJeY X* ‘ 

'' \Joict 


7. Given the following parameters: 

- G.711 CODEC 

10 ms Voice sample 
IP packet header is 40 bytes 


i ' u 

i J 


- I( . dOrtf 7.0 0 °%% 

%00 0 
__ c~y & kr L p.s 


Ignoring Layer 2 information, what is the expected bandwidth required per 


call? 



a. 256 kbps 



b. 128 kbps 



c. 96 kbps 


M 

d. 80 kbps 


w 

A 


§8 
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Answers to Practice 

If you successfully completed the Practice and are confident with your 
understanding of the material, you have satisfied the lesson requirements. 


Notes 
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Summary 

In this lesson, you reviewed general information about packet telephony, such 
as voice sampling and bandwidth calculations, based upon different 
compression standards. You learned about basic differences in packet¬ 
switching models, such as VoIP, VoFR, and VoATM. You also learned how 
attributes of RTP and UDP make these protocols ideal to meet the needs of 
real-time applications. 



'/ 
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Packet Telephony Design Issues 


Introduction 

This lesson builds upon basic concepts covered in the previous lesson, such as: 
voice packetization, overhead, payload, bandwidth, compression, protocols, 
and types of packet-switched networks. 

In this lesson, you will learn packet design techniques to help ensure that the 
voice quality on the data network meets the customer’s expectations. 

Objectives 

Given this module and the instructor’s presentation, you will be able to 
complete these tasks: 

• Apply knowledge of latency and packet loss to select CODECs that meet 
the customer’s voice quality expectations 

• Determine bandwidth requirements based upon call volume and voice 
packetization parameters 

• Apply knowledge of the voice quality tests to express the level of voice 
quality 
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Voice Quality on a Data Network 

Performance of Speech CODECs Based Upon Compression 
Standards 

Speech CODECs (compression algorithms), such as G.729 and G.723, are 
intended to reduce the bandwidth required. The key is to select a CODEC that 
meets both the bandwidth and voice quality requirements. 


Figure 1: Speech Compression 



Voice Quality Measurement 

Two models that measure voice quality are: 

• Mean Opinion Score (MOS) 

• E-Model G. 107 

Both models are covered in greater detail, later in the lesson. 


Notes 
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Voice Quality Versus Bandwidth Reduction 

The trade-offs for reducing bandwidth are: 

• End-to-end delay (latency) 

• Distortion in voice quality 

The table below shows that the result of increased voice compression is 
increased delay and lower voice quality. 


Table 1: Performance of Speech CODECs Based Upon Compression Standards 


CODEC 

Sample Time 

Look Ahead 
Delay 

Minimum 
Compression 
Algorithm Delay 

Voice Quality 

G.711 (64 Kbps) 

.125 ms 

Not applicable 

.125 ms 

Toll quality 

G.729 (8 Kbps) 

10 ms 

5 ms 

15 ms 

Near toll quality 

G.723 (5.38/6.3 Kbps) 

30 ms 

7.5 ms 

37.5 ms 

Fair to good 


Note: Although there are many CODECs from which you can select, the 
CODECs used most often are G.711 and G.729. Values listed in the table are 
estimates. 


© @ • © 0 # • 


Notes 






Issue 2.0 January 6, 2003 


Packet Telephony Design Issues 




















Page 4 of 26 


All Networks Experience Delay 

Although some CODECs have a higher compression algorithm delay 
(encoding and decoding time), all networks experience some delay. 

Packet delay has a significant impact on the perceived quality of a voice. To 
improve overall Quality of Service (QoS), it is vital to detect the delay and 
compensate for it. Techniques, such as queueing and prioritization, can 
significantly improve overall network performance and voice quality. 

You will learn more about QoS mechanisms in the next lesson. 

—Tip: Delay should he less than 150 to 200 ms to avoid complaints, 
depending upon the types of applications used and customer 
~ requirements. 


Two Types of Delay 

There are two types of delay: 

• End-to-end delay (latency) 

• Variable delay (jitter) 


Notes 
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End-to-End Delay (Latency) 

End-to-end delay (latency) is a non-variable (fixed) value. It is the time 
between the generation of a sound at one end and the reception of the sound at 
the other end. 

Figure 2: End-to-End Delay (Latency) 


Queue 



Some factors that influence end-to-end delay are: 

• Processing: Time needed to encode, packetize, and decode the 
transmission 

• Propagation: Distance between source and destination 

• Data network transmission: Link speed (per network segment) 


» * 
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Variable Delay (Jitter) 

Variable Delay (jitter) is dynamic. Jitter produces gaps in the conversation due 
to an uneven flow of data. 

Factors that Impact Variable Delay (Jitter) 

Some factors that contribute to jitter are: 

• Performance of the network during peak conditions 

• Packet contention for network devices 

• Speed of links 

• Size of voice and data packets 

• Size of router buffers 

However, uncontrollable jitter impacts packet loss. See the “Packet Loss” 
section, later in this lesson, for additional information about packet loss. 


Figure 3: Variable Delay (Jitter) 
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Techniques to Compensate for Delay 

Some techniques to compensate for delay are: 

• Differentiated Services (DiffServ): Allows you to define different service 
classes and QoS mechanisms for packets (Layer 3) 

• Resource ReSerVation Protocol (RSVP): Allows the receivers to reserve 
a dedicated portion of the network's bandwidth 

• Ethernet 802 Standards: Provide congestion management at LAN port 
and user levels (802.Ip and 802.IQ) 

• Port-based Prioritization: Allows you to configure a Layer 2 switch to 
prioritize all traffic originating from a specific port; for example, a VoIP 
gateway 

• Traffic Separation: Allows you to separate voice and data traffic via a 
virtual LAN (VLAN) 

• IP Address Prioritization: Allows you to prioritize all packets originating 
from designated IP addresses 

You will learn more about these techniques in the next lesson. 



* 

J* 
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Packet Loss 

Sometimes packets fail to arrive at the destination. This creates gaps in 
conversation that degrade the voice quality; for example, clicks, muting, or 
unintelligible speech. 

Figure 4: Packet Loss 




Tip: Keep packet loss below one percent. 
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Factors that Impact Packet Loss 

Some factors that impact packet loss are: 

• Congestion: Router discards packets to reduce congestion, or the buffer 
overflows 

• Service Disruption: Network experiences an outage 

• Delay: Some packets take a longer route or experience delays that prevent 
them from reaching their destination at the appropriate time 

• CODEC Selection: Coding and decoding delay; for example, G.723 has a 
higher algorithmic delay than G.711, which can impact voice quality 



Caution: Packet loss will vary, depending upon the compression 
method (CODEC) used. Higher compression ratios increase the 
susceptibility of voice quality to packet loss. 



Techniques to Control Packet Loss 

Ways to avoid packet loss include: 

• QoS Protocols: Expedite the transmission of voice packets at the various 
gateways and routers, minimizing jitter and its resultant lost packets 

• Call Admission Control: Limits the number of calls that can be active at 
various network nodes 

• Adaptive Jitter Buffer: Adjusts the jitter buffer delay 

• Packet Loss Concealment: Smooths gaps in audio 

• Bandwidth Increase: Increases bandwidth to handle peak traffic loads; 
compensates for packet loss that is often concealed by the retransmissions 
of data protocols 


• % 


Notes 



Issue 2.0 January 6, 2003 


Packet Telephony Design Issues 






Page 10 of 26 


Example: Delay 

The figure below provides an example of the delays that a voice packet 
experiences as the packet moves through the WAN. Contrast this example with 
the figure on the next page that uses T1 links. 


Figure 5: Estimated Latency: 56 Kbps WAN Links 
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Figure 6: Estimated Latency: T1 WAN Links 
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Echo Impairment and Control 


Echo Impairment 

Echo that is inaudible in the circuit-switched network can become noticeable 
with packet transmission because of the increased delay. 

Two factors that impact the severity of an echo are: 

• The amplitude of the echoed signal 

• The time it takes to return to the speaker 



Tip: It is important to detect and remove echo greater than 28 ms. 


Notes 



Packet Telephony Design Issues 


Issue 2.0 January 6, 2003 






Devices to Control Echo 

Devices that control echo are: 

• Echo Canceller: An echo canceller is a device that looks for echo (a delay 
on the return path that is strongly correlated with a signal seen on the 
incoming path) and uses an adaptive filter to model the echo and then 
subtract it from the return signal. An echo canceller can improve the echo 
path loss of a connection by up to 26 to 30 dB with the adaptive filter. Any 
residual echo is removed using a non-linear processor, which removes all 
signals below a certain threshold. 

• Echo Suppressor: An echo suppressor, or voice switch, is a device that 
detects a signal on the incoming or outgoing path and switches attenuation 
into the other path to reduce the level of any returning signal. This 
suppression technique can be used in speakerphones, headsets, and 
wireless handsets. 
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Calculating Bandwidth 

In the previous lesson, you learned how CODEC selection impacts the packet 

overhead. Another important factor is the data link layer network technology 

that is used. 

For example, assuming a 40-byte base IP header: 

• If you are using a Point-to-Point Protocol link, add 8 bytes to the base 
header size, for a total header size of 48 bytes. 

• If you are using a Frame Relay link, add 6 bytes to the base header size, for 
a total header size of 46 bytes. (If you are using longer Frame Relay 
addresses, this value will be higher.) 

• If you are using Ethernet (802.3), add 18 bytes to the base header size, for a 
total header size of 58 bytes. (If you are using 802. IQ tagging, this value 
will be higher.) 

See the table below for details. See the next page for the calculations. 

Figure 7: How Link Layers Impact Overhead 
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Example 1: 

• CODEC G.711 = 64 Kbps \ 

• Voice payload (sample) = 10 msi(80 bytes) 

• IP header = 40 bytes V '-' 0 ' JJ 

• Link type = 802.3 (Ethernet) 18 bytes 

• IP packets per second = 100 

The math: (80 + 58) x 8 x 100 = 110,400 (110.4 Kbps) 

_ . o C ls ^ fi&xioo r T 

Example 2: v 

• CODEC G.729 = 8 Kbps 

• Voice payload (sample) = 10 ms (10 bytes) ) r 

• IP header = 40 bytes 

• Link type = PPP 8 bytes 

• IP packets per second = 100 

The math: (10 + 48) x 8 x 100 = 46,400 (46.4 Kbps) 

(JO+4o X/Oo c J 


[0\AAi )C & 


-> yOVAA^X 1 


Notes 
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Knowledge Check 

The following figure shows bandwidth requirements per call and maximum 
number of voice calls depending on voice CODEC, voice payload and link 
speed for Ethernet, Frame Relay and Asynchronous Transfer Mode (ATM) 
networks. Use the figure below to answer the questions that begin on the next 
page. 

Important: The table assumes an 85 percent theoretical throughput. 


6.711 ^.7Z9 


Codec Bit Rate 

64kbps 

8kbps 


10 

20 

30 

10 

20 

30 

IP Payload size (bytes) 

80 

160 

240 

10 

20 

30 

IP Packet size (40 byte header) 

120 

200 

280 

50 

60 

70 

Ethernet 






Ethernet bytes (per packet) 

150 

230 

310 

80 

90 

100 

Ethernet bandwidth per voice flow 
(kbps) 

130 

96.8 

85.9 

73.6 

40.8 

29.9 

Number of Voice Calls, Assuming 50% Link Utilization 

or Voice Traffic 

10 Mbps 

38 

51 

58 

67 

122 

167 

100Mbps 

385 

516 

582 

679 

1225 

1674 

1 Gbps 

3858 

5165 

5823 

6793 

12254 

16742 

Frame Relay 

Frame Relay bytes (per packet) 

124 

204 

284 

54 

64 

74 

Frame Relay bandwidth per voice flow 
(kbps) 

100 

82.0 

76.0 

44.0 

26.0 

20.0 

Number of Voice Calls, Assuming 50% Link Utilization for Voice Traffic 

64 kbps 

0 . 

0 

0 

0 

1 

1 

128kbps 

0 

0 

0 

1 

2 

3 

384 kbps 

1 

2 

2 

4 

7 

9 

512 kbps 

2 

3 

3 

5 

9 

12 

1.54Mbps 

7 

9 

10 

12 

29 

38 

2.048 Mbps 

10 

12 

13 

23 

39 

51 

45Mbps 

225 

274 

296 

511 

865 

1125 

ATM 

ATM cells required 

3 

5 

6 

2 

2 

2 

ATM payload in bytes (per packet) 

120 

200 

280 

50 

60 

70 

ATM bandwidth per voice flow (kbps) 

127.2 

106.0 

84.8 

84.8 

42.4 

28.3 

Number of Voice Calls, Assuming 50% Link Utilization 

for Voice Traffic 

1.54Mbps 

6 

7 

9 

9 

18 

27 

2.048 Mbps 

8 

9 

12 

12 

24 

36 

45Mbps 

176 

212 

265 

265 

530 

796 

155Mbps 

609 

731 

914 

914 

1827 

2742 
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Questions: 


1. Given the following parameters: 


CODEC is G.729 

Voice packet payload is 10 ms ^ Z V& 
1.544 Mbps Frame Relay link ^ 


oo°/jo c 


Assuming 50 percent link utilization, how many simultaneous calls can be 
made over the link? pp § 

(\ (2 -+ 6) y| QO a S r4^SOO ^?s 

a. 7 

b. i7 is//4^h s r 177 


a. 7 

b. 17 

c. 27 

d. 37 


7^7 14 


^ 17 


2. Given the following parameters: 


CODEC is G.711 . loo \OU s 

Voice packet payload is 20 ms fx£)-=: 

100 Mbps Ethernet link 1 8 

Assuming 50 percent link utilization, how many simultaneous calls can be 


made over the link? 

a. 225 

b. 316 

c. 425 

d. 516 


A O O 


(I40+4-O + I s') X- = b , 

2,4 = 3^00 ; vfcpS 

l00 nb F = icoooartps i—- 

50000# \J 7,2 14 - 


5 7 ^ 
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3. Given the following parameters: 


a. CODEC is G.711 

b. Voice packet payload is 30 ms (* &' ~ : 

c. 128 kbps Frame Relay link 


i (ioq/ 3, o — 3 3 y 3 


Assuming 50 percent link utilization, how many simultaneous calls can be 
made over the link? 40 + 6 ^ 

" - 76 , 4 ^ ' 

C3° \7?Y-bf? _ 

b - 5 l . 

c. 10 44 %s (. 

4 15 * - (3 ' 

4. The customer needs the ability to make 385 simultaneous calls on their 
Ethernet network with 50 percent link utilization for voice calls. The 
customer wants to ensure maximum voice quality. Based upon this request, 
what are your recommendations to the customer about the minimum 
requirements t^j meet this need? 

a. Gv729 CODEC 

/ 

20 ms/Voice Sample 
10 Mbps Ethernet link 

b. G.711 CODEC 

30 ms Voice Sample 
10 Mbps Ethernet link 

c. \ G.711 CODEC 

10 ms Voice Sample 
100 Mbps Ethernet link 

d. G.729.CODEC 

20 ms Voice Sample 
1 Gbps Ethernet link 
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Common Models for Voice Quality 

Once the voice quality and delay budget profiles have been outlined, it is 
important to monitor the voice quality of the VoIP network. Two common 
models used to measure voice quality are: 

• Mean Opinion Score (ITU P.800) 

• E-Model (ITU G. 107) 

Mean Opinion Score 

Mean Opinion Score (ITU P.800) 

The Mean Opinion Score (MOS) is a subjective rating used to rank voice 
quality. It uses these benchmarks: 

• 5 = Person-to-Person (excellent) 

• 4 - Phone quality (good) 

• 3 = Adequately understandable, but not very good quality (fair) 

• 2 = Can understand words, but cannot recognize speaker (poor) 

• 1 = Cannot understand words or recognize the speaker (bad) 

An MOS of 4.0 is considered good. An MOS of 3.6 or less is considered poor. 

The MOS is generally used with circuit-switched environments. For VoIP, the 
E-Model is recommended. See the next section for details. 
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E-Model 

The E-Model is a transmission-planning tool for estimating the user 
satisfaction of a narrowband (300 to 3400 Hz) handset conversation, as 
perceived by the listener. It is defined in ITU G.107. The E-Model is well- 
suited for VoIP. The output of the E-Model is the Rating Factor, the R-Value, or 
simply R. 

The scale is typically from 50 to 94, where everything below 50 is clearly 
unacceptable and everything above 94.15 (the maximum with the G.107 E- 
Model version 19 default values at 0 ms) is unobtainable in narrowband 
telephony. 

R is calculated from a number of parameters, such as loudness, echo, and 
delay, but it takes into account the effects of packet loss and speech 
compression codecs with the equipment impairment factor. 

The basic equation for the model is: 


R = Ro - Is - Id - le + A 

Where: 

• Ro = Base R-Value, such as noise 

• Is = Impairments that are simultaneous to speech, such as echo 

• Id = Impairments that are delayed after speech 

• Ie = Impairments due to the effects of special equipment, such as codecs 

• A = Advantage factor (to take account of user advantages, such as 

mobility) 
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R-Value 

The R-Value is calculated on a value called the Impairment Factor. The 
Impairment Factor is based on parameters, such as: loudness, echo, delay, 

Recommended Minimum R-Value 

The recommended minimum R-Value is 70. An R-Value under 50 is 
considered unacceptable. An R-Value greater than 94.5 is considered 
unobtainable in narrowband telephony. 

R-Value Mapped to MOS 

Once an R-Value is obtained, it can be mapped to an estimated MOS, as shown 
in the below figure. 


Figure 8: R-Value Mapped to MOS 
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Practice 

Answer the following questions. 

1. Given the following parameters: 

Voice Activity Detection (VAD) is disabled 

- CODEC is G.711 

Voice packet payload is 20 ms ( 2 ) “ Ho 

- 40 simultaneous calls 


/$Ofr/2 d w S c 


What is the approximate bandwidth required for running on an Ethernet 
LAN network? f \ (?o +&Q * $ ° * t 

2 —=> 

1 O 1 0 o 


a. 2 Mbps 

b. 2.5 Mbps 

c. 3 Mbps 

d. ) 3.5 Mbps 

2. Given the following parameters: 


2!Z OO rs7, / ^ 


g7, Z 

^ o 

' v * 


n 


Voice Activity Detection (VAD) is disabled 
- CODEC is G.729 

Voice packet payload is 40 ms ( i ) - A®*''* s " ~ 

Link type is PPP 

What is the approximate bandwidth required? 

i 


a. iuts.ops 

b. 14 Kbps 
J 8 Kbps 

d. 22 Kbps 
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3. Given the following parameters: 


Voice Activity Detection (VAD) is disabled 
- CODEC is G.729 

Voice packet payload is 60 ms (j) -5 £0 
1.544 Mbps Frame Relay link 


loop 

oiO b L 
4 —— 


Assuming 60 percent link utilization, how many simultaneous calls can be 
made over the link? ( Q 0 D x ! d, 6 >' g 

- I i\ 016 . i kfS 


a. 55 

b. ) 65 

c. 110 

d. 130 

4. Given the following parameters: 




. £4 4 

v 
y; -= 


|g<# 


12M0£_- 6V.S1 


Voice Activity Detection (VAD) is disabled 
- CODEC is G.711 33 

Voice packet payload is 30 ms (& )" 2 4 ® 

100 Mbps Ethernet switched LAN 


Approximately how many IP phones can make simultaneous calls if Call 
Admission Control (CAC) limits VoIP bandwidth to 20 Mbps? 


a v 

250 

+ 7 ^ 7 ’ 2 ... W M 

20 oOO*""?' 5 

b. 

275 


c. 

300 


d. 

325 



5. Which non-variable value is the time between the generation of sound at 
one end and the reception of the sound at the other end? 

a. Jitter 

b. Buffer 

c. End-to-End Delay (Latency) 

d. Endtime 
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6 . Which variable value is dynamic and affects the total time between the 
generation of sound at one end and the reception of the sound at the other 
end? 

a. Variable Delay (Jitter) 

b. Buffer 

c. End-to-End packet 

d. Endtime 

7. What mechanism allows you to define different service classes and QoS 
mechanisms for packets? 

a. RSVP 

b. DiffServ 

c. VLAN 

d. Port Prioritization 

8 . A customer needs toll quality for their VoIP network. What MOS is 
considered toll quality? 

a. 1 

b. 2 

c. 3 

® 4 

9. Using the E-Model, what R-value is the recommended minimum? 

a. 70 

b. 60 

c. 50 

d. 40 
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Answers to Practice 

If you successfully completed the Practice and are confident with your 
understanding of the material, you have satisfied the lesson requirements. 
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Summary 

In this lesson, you learned about factors that impact QoS, such as: 

• CODEC selection 

• Delay 

• Echo 

• Bandwidth 

You also learned about techniques to ensure that the voice quality on the data 
network meets the customer’s expectations, including models to measure the 
voice quality on a network. 
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Lesson Template.FM Issue 4.00 October 15,1998 



Traffic Convergence Issues 


Introduction 

Most data networks are structured to treat all traffic the same. The traffic can 
experience different amounts of delay and packet loss at any given time. 
Because of this structure, data networks are referred to as best-effort networks. 
This can result in poor voice quality. In contrast, voice networks are structured 
so that voice traffic experiences a fixed amount of delay and essentially no 
packet loss. This results in very high quality voice. 

This lesson identifies some key issues that you may encounter with the 
deployment of a Voice over Internet Protocol (VoIP) solution over a Local Area 
Network (LAN) and Wide Area Network (WAN). It also describes techniques 
you can use to achieve End-to-End Quality of Service (QoS). 

Objectives 

Given the student guide and the instructor’s presentation, you will be able to: 

• Discriminate between the various methods available for implementing QoS 
prioritization of VoIP traffic to achieve the best voice quality 

• Explain the issues and challenges of running VoIP over low speed WAN 
connections 

• Define the key infrastructure needed to support the addition of VoIP traffic 
in the LAN and WAN environments 

• Identify common Ethernet network issues known to be problematic for 
VoIP traffic in a LAN environment 




Notes 
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What is Quality of Service? 

There are many perceptions regarding QoS. Some of the more common views 
of QoS follow: 

• QoS is the perception of overall voice quality by the user 

• QoS is dependent on the characteristics of the IP network 

• QoS is governed by the differences between cost and quality 

• QoS delivers availability, reliability, and predictability 

• QoS has the ability to prioritize traffic flows 

• QoS manages customer's expectations through Service Level Agreements 
(SLAs) 

Factors that Impact Quality of Service 

QoS involves a broad range of technologies, architecture, and protocols. 
Network operators achieve end-to-end QoS by ensuring that network elements 
apply consistent treatment to traffic flows across the network. 

However, QoS for VoIP largely depends on these network parameters: 

• Jitter 

• Delay 

• Packet loss 


® © © 
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Methods to Achieve Quality of Service 

QoS is an architecture that delivers availability, reliability, and predictability 
for prioritizing traffic flows. Service Providers can use QoS to provide Service 
SLAs to customers and help manage their expectations. Network operators 
achieve end-to-end QoS by ensuring that network elements apply consistent 
treatment to traffic flows as they traverse the network. 

Some methods to achieve quality of service for VoIP traffic are: 

• Resource ReSerVation Protocol (RSVP): Allows the receivers to reserve 
a dedicated portion of the network's bandwidth 

• Differentiated Services (DiffServ): Allows you to define different service 
classes and QoS mechanisms for packets 

• Ethernet 802 Standards: Provide congestion management at LAN port 
and user levels 

• Port-based Prioritization: Allows you to configure a Layer 2 switch to 
prioritize all traffic originating from a specific port; for example, a VoIP 
gateway 

• Traffic Separation: Allows you to separate voice and data traffic via a 
virtual LAN (VLAN) 

• IP Address Prioritization: Allows you to prioritize all packets originating 
from designated IP addresses 

• Packet Fragmentation: Allows you to fragment packets prior to 
traversing bandwidth-limited connections 

Note: When implementing QoS, also consider routing protocols. Routing 
protocols can be very important when considering how VoIP calls will be 
routed and how quickly fail-over occurs. When planning deployment of VoIP, 
the network designer must be aware of what types of situations trigger a 
routing table update with respect to the routing protocol. This helps predict 
what path VoIP traffic can take when a network failure occurs. 


© 


© 
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Resource Reservation Protocol 

Resource Reservation Protocol 

Resource ReSerVation Protocol (RSVP) is a type of network resource 
reservation. RSVP reserves bandwidth and other resources on routers located 
throughout a network for a transmission path. All routers in the network path 
must be RSVP-compliant for this priority. RSVP is allocated on a first-come, 
first-served basis and ties up the amount of bandwidth needed for processing 
an application. RSVP depends on a router’s Routing Information Protocol 
(RIP) and Open Shortest Path First (OSPF) decision-making for transmission. 


Figure 9: Resource Reservation Protocol 
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Differentiated Services 

Differentiated Services (DiffServ) is a type of packet prioritization. 

DiffServ enables you to specify and control network traffic by class so that 
certain types of traffic get precedence; for example, voice traffic, which 
requires a relatively uninterrupted flow of data, can get precedence over other 
kinds of traffic. It is also an effective method to maintain QoS when a company 
has a combination of Layer 2 and Layer 3 switches. 


Figure 10: Differentiated Services 



Notes 
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Class of Service 

DiffServ is the most advanced method for managing traffic in terms of what is 
called Class of Service (CoS). Unlike the earlier mechanisms of 802.Ip 
tagging and Type of Service (ToS), DiffServ avoids simple priority tagging and 
depends on more complex policy or rule statements to determine how to 
forward a given network packet. 

For a given set of packet travel rules, a packet is given one of 64 possible 
forwarding behaviors. Of these fields: 

• 32 are for public use (21 are standardized by the IETF) 

• 32 are experimental 

Differentiated Services Code Point Field 

A six-bit field, known as the Differentiated Services Code Point (DSCP), in the 
Internet Protocol (IP) header specifies the per hop behavior for a given flow of 
packets. 

Figure 11: DSCP Field 


4 bit 
version 

4 bit 
header 
length 

8 bit Type of 
Service (TOS) 

16 bit total length (in bytes) 

more header info.... 


0 1 2 3 4 5 &ML 


» 

1 

DSCP i CU 



* CU = currently unused 






Notes 







I 



Traffic Convergence Issues 


Issue 2.0 January 6, 2003 










Class Selector (CS) 

The Class Selector (CS) of DiffServ behavior is represented by eight priority 
classes and uses the same bit positions as the IP Precedence field in ToS. The 
classes are numbered from CSO to CS7. CS7 has the highest priority. CSO is 
equivalent to best-effort service. 


Expedited Forwarding and Assured Forwarding 

Expedited Forwarding (EF) and Assured Forwarding (AF) allow you to 
prioritize VoIP traffic and signaling. 


\ EF provides a low-latency, high-priority service that is suited for VoIP. 


5 


\ 


AF consists of four different service classes, each with three different discard- 
priority levels. Class 4 has priority over Class 3, and so on. 
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Ethernet 802 Standards 

Congestion management defines how different queuing categories, such as 
Ethernet 802 standards 802.Ip and 802.IQ, prioritize packet transmission. 

802. Ip and 802.IQ define prioritization of traffic within a LAN. In defining 
these standards, 802-type priority traffic is processed and placed in front of less 
critical business traffic. 802.Ip is the level assigned at the user level, while 
802.1Q is assigned at the LAN port level. 

Ethernet 802.1 Q 

Ethernet 802.IQ is an Institute of Electrical and Electronics Engineers (IEEE) 
Ethernet standard that adds four additional bytes to the standard 802.3 Ethernet 
frame for Ethernet QoS and Virtual LAN (VLAN) support. Most Ethernet 
switches support the 802.IQ standard, with the exception of perhaps the least 
expensive ones. 


Figure 12: Ethernet 802.1 Q 
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Ethernet 802.IQ prioritizes packet transmission at the LAN port level: 

• Untagged frames from End User A and End User B arrive simultaneously 
at port 4 of a switch. 

• Port 4 has a priority value of 6 for VLAN X (End User A) and a priority 
value of 4 for VLAN Y (End User B). If End User A frames exit the switch 
on an 802.IQ tagged port, exiting End User A frames would also be 

802.IQ tagged, including the 802.Ip user priority of 6. 

• End User A frames are sent before End User B frames. 


Note: If a tagged frame enters the switch on a tagged port, when it exits the 
frame retains both tags, the port and user priority. If a tagged frame exits the 
switch on a port that is an untagged member of a LAN, the frame exits the 
switch untagged (regardless of whether it came in tagged or not) and the user 
priority value is lost. 


• ••«•••••«•••••• 
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Ethernet 802.1 p 

Ethernet 802.Ip (802.Ip) is an effective method to maintain QoS when a 
company has a combination of Layer 2 and Layer 3 switches. The Ethernet 
QoS is accomplished through the three 802.Ip user priority bits. The 802.Ip 
user priority bits allow you to create eight classes of service for packets that 
cross Ethernet networks. Based upon the 802.Ip value, each packet is placed in 
the correct queue. 

Figure 13: Ethernet 802.1 p 



802.Ip is used to prioritize packet transmission 
at the user level. 
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Ethernet 802. Ip prioritizes packet transmission at the user level: 

• Frames for End User A and End User B arrive simultaneously at the switch 
for transmission. End User A frames have a priority of 6, while End User B 
frames have a priority of 5. 

• Based on priority levels. End User A frames are processed first, while End 
User B frames are queued and transmitted when End User A transmission 
is complete. 

• Frames for End User C are not assigned a priority. The frames are 
transmitted after the prioritized frames. 

Note: If this network policy is assigned in the entire network, this will be true 

on all switches. 
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Port-based Prioritization 


Port-based Prioritization is an effective method to achieve optimal voice 
quality. With Port-based Prioritization, you can prioritize all traffic coming 
from the specific port of an Ethernet Layer 2 switch. In this case, 802. Ip is not 
required, because you are prioritizing all traffic coming in on this port. 


2 


If th e device attached to the Layer 2 switch port is an IP phone, then port 
prioritization is hot recommended since IP terminals can be unplugged and 
moved. If a PC is connected to a port configured to use port prioritization, then 
all of the PC’s traffic is given high priority treatment. 

Protocols 


Products can use UDP port ranges to provide high priority to VoIP packets as a 
form of QoS in existing legacy IP networks. The same port ranges must be 
reserved and set to high priority on all routers where an administrator expects 
to have QoS support. DiffServ networks do not require a reservation of port 
ranges. You can designate any port range that is not used by well-known 
protocols and applications. Each H.323 or VoIP RTP flow uses two ports for 
each direction. The total number of UDP port numbers to be reserved depends 
on how many concurrent RTP flows are expected to cross a router interface. 

Guidelines 


Remember the following guidelines: 

• Backbone routers reserve more ports than edge routers 

• Port ranges on edge routers are a subset of backbone router port ranges 

• Two ports must be reserved for each call expected to be carried over WAN 
link 

Note: H.323 is a packet-based signaling standard that provides a foundation 
for audio, video, and data communications across IP-based networks. See the 
“VoIP Standardization and Signaling Protocols” lesson, later in this course. 


Notes 
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Traffic Separation 

Traffic Separation is an optional technique. 

If all Ethernet switches support the Ethernet 802.IQ standard for VLANs, then 
Traffic Separation with VLANs enables you to place all voice traffic onto one 
VLAN and all other data traffic on another VLAN. 

Benefits of Traffic Separation are: 

| • Enables you to ensure voice QoS by allowing voice VLAN traffic to have a 

higher priority over the data VLAN traffic 

c\ • Provides an easy way to connect a VoIP gateway from an IP-enabled 

switch to the company’s existing Ethernet Layer 2 switch using only Layer 
! 2 technology 



Caution: Not all vendors recommend the use of VLAN. Use of VLAN 
depends upon the customer requirements. 


Internet Protocol Address Prioritization 

VoIP traffic can also be prioritized by its IP address. This approach is ideal for 
devices with static IP addresses that rarely, if ever, change. IP Private Branch 
Exchanges (PBXs), VoIP gateways, and call servers are VoIP devices that can 
have static IP address assignments. A network administrator can configure the 
routers to filter (classify) and prioritize all packets originating from these IP 
addresses and know they are from VoIP devices. 
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Packet Fragmentation 

In mixed voice and data IP networks, packets must be fragmented prior to 
traversing bandwidth-limited (less than 1 Mbps) connections to minimize 
voice delay and jitter. There are several different protocols that can be used to 
fragment packets. 



Tip: There are two types of fragmentation that are more universal and 
not limited to a specific link layer technology such as ATM or Frame 
Relay FR.12. These methods are via the PPP protocol and via IP 
fragmentation. 


Frame Relay FRF.12 

For Frame Relay connections, you can use the FRF.12 standard for 
fragmenting packets. 

Point to Point Protocol Fragmentation and Interleaving 

Many routers support PPP Fragmentation. PPP Fragmentation splits large 
packets into multiple smaller packets and encapsulates them into PPP frames 
before queuing and transmission. PPP Fragmentation allows higher-priority 
VoIP packets to interrupt and transmit ahead of the larger, lower priority 
packets that have already been queued. The packets can be interleaved, so the 
maximum delay a voice packet experiences is one packet time. 

Asynchronous Transfer Mode 

ATM natively provides fragmentation. ATM packets are fragmented into 53- 
byte cells. 


# & • # • # 


Notes 



Traffic Convergence Issues 


Issue 2.0 January 6, 2003 






Page 15 of 32 


IP Fragmentation (Maximum Transmission Unit) 

Most routers use a default maximum packet size of 1500 bytes, which can take 
a considerable amount of time to transmit over a low bandwidth connection. 

Consider a 1,500-byte data packet being transmitted over a 64 Kbps 
connection. It takes 188 ms to transmit this data packet out of the router onto 
the 64 Kbps connection. This same queuing delay is added again as the packet 
is queued in at the far end router on the other side of the connection. 

Data packets use up almost all of the delay budget for the voice traffic before 
the first voice packet is ever transmitted. Reducing the MTU can put more data 
on the WAN sooner and is not necessarily as efficient. There is a trade-off 
between better network performance and voice quality. See the section titled 
“Maximum Transmission Unit” for additional information. 
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Challenges of Low Speed Wide Area Network Connections 

There are a number of items to consider when using routers with low 
bandwidth WAN and access network connections. 


Serialization Delay 

Serialization delay can occur when a small packet has to wait for a large packet 
to be sent over the link. This can result in end-to-end delay (latency) and 
variable delay (jitter). For example, when transporting smaller packets over a 
network infrastructure that typically has larger packets of up to 1,500 bytes, the 
larger packets can introduce variable delay (jitter) in the network and impact 
the voice quality. 

In a WAN environment where link speeds are low compared to the LAN, link 
speeds less than 1 Mbps are subject to serialization delay. See the figure below 
for details. 

Figure 14: Serialization Transmission Delay for Different Link Speeds 


Serialization transmission delay in msec, for different link speeds 
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Maximum Transmission Unit 

The Maximum Transmission Unit (MTU) is the maximum amount of bytes 
carried by any packet. When the access line is running at a low speed, smaller 
packets must wait behind the larger packets. 
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Maximum Transmission Unit Sizes 

A possible solution is to begin with an MTU size of 256 bytes for connections 
less than 1 Mbps and adjust upward, as needed. The table below shows the 
recommended maximum MTU sizes for different connection speeds. 


Table 2: Maximum Transmission Unit Sizes 


Link Speed 

56 Kbps 

64 Kbps 

128 Kbps 

256 Kbps 

512 Kbps 

Recommended Maximum 
MTU 

128 bytes 

v Vs w * 

128 bytes 

256 bytes 

512 bytes 

1024 bytes 

Ideal MTU 

70 bytes 

80 bytes 

160 bytes 

320 bytes 

640 bytes 


"v- 
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Caution: Remember, reducing the MTU can put more data on the 
WAN sooner and is not necessarily as efficient. There is a trade-off 
between improved network performance and voice quality. 
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Key Infrastructure Requirements 

Local Area Network Environment 

Half-Duplex Versus Full-Duplex Ethernet Connections 

Half-duplex is the term used to describe alternating transmissions over a 
communications link. Each station can either transmit or receive, but cannot do 
both simultaneously. Full-duplex data transmission is defined as the ability for 
communications to flow both ways simultaneously over a communications 
link. In Ethernet or Fast Ethernet networks, the collision detection and 
avoidance protocol is turned off and frame transmission occurs in both 
directions at the same time, doubling the available bandwidth on a link. 

Autonegotiation 

Autonegotiation is standard for Fast Ethernet. This standards enables two 
devices that share a common link to advertise their speed and duplex mode 
capabilities, acknowledge receipt and understanding of shared modes of 
operation, and reject modes of operation that are not shared. This allows the 
devices to leverage the maximum resources of each node. 

There are some things to watch for with autonegotiation. For autonegotiation 
to work, both sides must support autonegotiation. Occasionally customers will 
run into devices with outdated network interface card drivers that either do not 
support autonegotiate or incorrectly implement autonegotiate. After several 
attempts to make a connection, the link may stop trying to connect so that no 
communication occurs. Or perhaps the link is incorrectly established, such as 
10 Mbps on one end and 100 Mbps on the other end, or full-duplex on one end 
and half-duplex on the other end. 

To correct this type of mode mismatch problem, it may be necessary to dis able 
autonegotiation and set a fixed speed and duplex mode for t he l ocal port ( 10 
Mbps or 100 Mbps, half- or full-duplex) so that the modes coincide with the 
operating capabilities of the remote link. 
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Layer 3 Switches 

Layer 3 switches, also known as routing switches, combine the speed of a 
switch with the IP routing capability of a router. Traditional routers store their 
routing instructions in software. Layer 3 switches store their routing instruction 
in hardware. This allows Layer 3 switches to reduce latency by routing 
millions of packets per second. 



Tip: If a customer has a combination of Layer 2 and Layer 3 switches, 
802.Ip and DiffServ are effective methods to maintain toll quality QoS. 


Power Management 

Building power management into the IP network is important for increasing 
reliability of the VoIP network. Some ideas for implementing power 
management in your network: 

> • Power over LAN (sometimes called inline power) for IP terminals 

• Redundant power supplies for the network equipment 

• Uninterruptible Power Supply (UPS) 

• Sufficient cooling in wiring closets 

Note: If you have redundant power supplies, plug each power supply into a 
separate UPS. If possible, have each UPS on its own circuit. If one circuit fails, 
the other circuit still has power. 


• • * 
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Common Data Protocols and Applications 

Common data protocols and applications include: 


• File Transfer Protocol (FTP): Used to exchange files between computers. 
FTP can be used to transfer very large files and can be very bandwidth 
intensive. 


Tr $vtJ 


Telnet: Used to access other computers over TCP/IP. It is not very 
bandwidth intensive. 

Simple Mail Transfer Protocol (SMTP): Used to queue messages on a 
mail server. SMTP can be very bandwidth intensive. 

Hypertext Transfer Protocol (HTTP): Used by computers accessing web 
pages. This can be bandwidth intensive depending on what the user is 
accessing. 

Structured Query Language (SQL): Used to query information from a 
relational database, such as Oracle or Sybase. SQL is a very talkative 
protocol that should preferably be kept to one VLAN. 


• Domain Name Server (DNS): Used by computers to discover the IP 
address associated with a computer’s host name, or a name to go with an IP 

_ address. 

• Dynamic Host Configuration Protocol (DHCP): Used by computers to 
gather their initial network configuration information, such as host name, 
gateway, and subnet mask. It is not that talkative. 


Lack of Quality of Service in 802.11 Wireless Environment 

Wireless networks typically have longer delay then traditional media. The 
industry is still looking for ways to provide QoS on wireless networks. 
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Area Network Environment 

Importance of Quality of Service 

The same traffic queue management issues relevant on the LAN apply to the 
WAN, though with far greater complexity. The issue over WAN links, unless 
they are privately managed, is how much control your organization maintains 
once traffic leaves your private network for public connections. 

The WAN presents a challenge to guarantee consistent application 
performance because it has so many scenarios. 

For example, in a Frame Relay environment, a typical design can have many 
low-speed links that terminate at branch locations with high-speed links. The 
low-speed links can be overrun by traffic from the central site with a larger 
bandwidth connection. 


Figure 16: High-Speed Link Terminating in Low-Speed Links 



Wide 
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Evaluating Customer Routers 

There are three factors that influence router performance: 

• Baseline speed of a router: 

Performance of router, given the most favorable conditions 

• Characteristics of the routed traffic: 

Packets that arrive in bursts are delayed more than evenly-spaced 
packets. 

• External events (besides routed traffic): 

Interaction with other network devices 
Routing table maintenance 
- Address resolution 

Need for Call Admission Control 

J 

In networks with a high proportion of voice traffic, Call Admission Control 
(CAC) can prevent congestion by limiting the number of calls that can be 
active through various nodes in the network. With no CAC, when the number 
of calls increases above the recommended utilization, the voice quality in the 
network declines. 

For example, if the WAN access link between the two Private Branch 
Exchange (PBX) systems has the bandwidth to support only two VoIP calls, 
admitting the third call impairs the voice quality of all three calls. CAC allows 
a gateway to reject traffic once a defined threshold is reached on the gateway. 
After the call is rejected, the originating gateway must find another means of 
handling the call. There are several possibilities, most of which are dependent 
on the configuration of the gateway. 

Lack of Quality of Service in Frame Relay Environment 

Frame Relay networks provide no form of QoS other than the ability to mark 
traffic as Discard Eligible (DE). All traffic not marked DE receives the same 
treatment within a customer's Committed Information Rate (CIR). 


Notes 
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Security Issues 

Firewalls are designed to protect the internal network from the outside 
network. The design of a firewall can go from relatively simple firewalls that 
come preconfigured, to complex designs that incorporate multiple firewalls 
and proxy servers. For a firewall to work with VoIP, certain “holes” punched in 
the firewall for the VoIP ports or the firewall must understand the protocols 
going across the firewall, such as RTP, H.323, SIP, etc. Even if the firewall 
understands the VoIP protocols that a customer is using, it does not ensure that 
the customers will be able to call customers outside the firewall. 

Network Address Translations (NATs) 

Network Address Translations (NAT) permits a few IP addresses to be shared 
by many users. It also permits the connection of an intranet-based address (for 
example, 10.0.0.1) from accessing the internet. I f either party of a call uses 
NAT there can be a problem creating a call because the IP information is not 
only written in the IP header t hat gets exchanged by the NAT server,butal$o 
deep er in some packets, f or example SIP packets. Some newer NAT servers 
and firewalls are being developed that understand RTP, H.323, and SIP, but 
older ones may not. 

Encryption 

One solution that allows voice traffic to cross a firewall and also avoid the 
issues raised by NAT is to create a VPN where both machines are on the same 
VPN network. Therefore, traffic is tunneled through firewalls. This may cause 
added delay, however, making VoIP unusable. 




• « • • 
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Common Ethernet Network Issues for LAN Environment 


Bandwidth 

VoIP requires bandwidth of 10/100 Ethernet switching. 


Tip: For low-bandwidth (less than 1 Mbps) connections, it is 
recommended to use no more than 50 percent of the available 
bandwidth for voice traffic. For connections greater than 1 Mbps, you 
can use up to 85 percent of the available bandwidth for voice traffic. 


Compression 

There are several possible choices for voice compression. The ITU G.729 
CODEC generally provides the lowest bandwidth with the highest voice 
quality. G.729 compresses the voice call from approximately 64 Kbps to 8 
Kbps. This 8 Kbps is the raw-voice bandwidth and needs to be encapsulated 
into other protocols before it becomes VoIP and can be transported over an IP 
network. The link layer protocol to transport the IP packet could be PPP, Frame 
Relay, or ATM. The additional overhead added by these protocols increases 
bandwidth required for VoIP packets to approximately 20 to 28 Kbps. 

Remember, bandwidth requirements are estimates, and vary per product or 
packetization parameter settings. 

V Tip: Voice compression is not required over high bandwidth, Ethernet 
connections. 
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Delay 

The overall delay budget for a voice call, from the time you speak until the 
time the receiver hears your voice, must typically be no longer than 150 ms for 
good quality voice over landline connections. 


Congestion 

Ethernet networks require less sophisticated QoS mechanisms than low- 
bandwidth WAN connections because the bandwidth is much higher resulting 
in significantly lower queuing and network delay. However, network 
congestion, even for short periods of time, and bursty, TCP-based Internet 
traffic can cause significant voice quality problems if QoS is not applied. 

Note: Only use switched-media Ethernet networks with VoIP. Never use 
shared-media Ethernet hubs. QoS mechanisms, such as 802.Ip, VLANs, and 
port prioritization, can be used for VoIP traffic over Ethernet networks. If the 
Ethernet switches support Layer 3 capabilities, then QoS mechanisms, such as 
DiffServ and IP address prioritization, can also be used. 


« • ••••••••••••••••••••••• 
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Collision 

In an Ethernet environment, collisions occur more frequently as utilization 
levels increase. This can cause unpredictable delays between packets due to the 
access protocols associated with Ethernet LANs, where a random exponential 
back-off algorithm is used after a collision is detected. 

If utilization level exceeds 50 percent, voice-encoded packets generally will 
flow to the router for transmission on the Intranet, with unpredictable delays 
between packets. 

At a minimum, Layer 2 switching is required to avoid network collision. 


Packet Reordering 

In some cases there can be multiple paths for a VoIP packet to take when 
traveling from its source to its destination. If all VoIP packets do not take the 
same path, then packets can arrive out of order. This can cause voice quality 
issues; however, packet reordering often has little or no adverse impact to data 
traffic quality. 


% 
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Practice 

Answer the following questions. 



1. What is a benefit of Traffic Separation using VLANs? 

- € l o tts+aut 'yna Qo3 7 *>c<- \/LAfJ 
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2. How does Port-Based Prioritization achieve optimal voice quality? ‘ 
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3. Ethernet 802.Ip is required for Port-Based Prioritization. 

a. True 

b. False 

4. Frame Relay FRF. 12 natively provides fragmentation since all packets are 
fragmented into 53-byte frames. 

a. True 
( b. False 


• • • e 


• • @ e • 


Notes 



Traffic Convergence Issues 


Issue 2.0 January 6, 2003 







Page 29 of 32 



5. What is the difference between Expedited Forwarding and Assured 
Forwarding DiffServ classes? 



6. What is the recommended Maximum MTU for VoIP at 256 Kbps? 

^ \ 2 


7. List three ideas for implementing power management in your network. 
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Answers to Practice 

If you successfully completed the Practice and are confident of your 
understanding of the material, you have satisfied the lesson requirements 






& 


© 
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Summary 

In this lesson, you learned the distinction between the various methods 
available for implementing QoS prioritization of VoIP traffic in order to 
achieve the best voice quality. You have an understanding of the challenges of 
running VoIP over low speed WAN connections. You learned about the 
infrastructure needed to support VoIP traffic in the LAN and WAN 
environment and the common Ethernet problems associated with this traffic. 



Notes 
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Lesson Template.FM Issue 4.00 October 15,1998 




VoIP Standardization and Signaling 
Protocols 


Introduction 

The Internet is a popular and widely used communications network. It uses 
Internet Protocol (IP), the most scalable, flexible network technology capable 
of working across any network infrastructure. IP is a universal 
communications language that provides the foundation to allow dissimilar 
physical networks and equipment from a variety of vendors to interconnect. IP 
allows computers to share resources across networks and application protocols 
that support communication services, such as the World Wide Web (WWW). 
Computers understand IP without a translator, which can allow them to 
function as a coordinated unit with an IP network. 

A relatively new technology that utilizes the IP network is Voice over IP 
(VoIP). VoIP provides real-time communication and requires a greater QoS and 
more bandwidth than most applications. VoIP uses packet-switched 
connections to transmit real-time two-way voice traffic, faxes, and other 
information. These transmissions have traditionally been processed through 
the dedicated circuit-switched connections of the Public Switched Telephony 
Network (PSTN). 

For communications to be successfully transported over the IP network, 
standards exist that utilize signaling protocols to accomplish this task. These 
standards have been determined and introduced by organizations specifically 
designated to define communications standards for transmission of voice, 
video, and data. In this lesson, we will review the VoIP standards and 
networking protocols that support the transport of communications across IP- 
based networks. 




Notes 
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Objectives 

Given this module and the instructor’s presentation, you will be able to 

complete these tasks: 

• List organizations instrumental in defining and developing Voice over 
Internet Protocol (VoIP) standards 

• Identify the role H.323 plays within a VoIP network 

• Apply H.323 standards to a VoIP Environment during call setup 
implementation 

• Identify the role of Session Initial on Protocol (SIP) in IP Telephony 

• Recognize the role of SIP in supporting multimedia sessions with IP 
Telephony 

• Differentiate the benefits and functionality of SIP versus H.323 within a 
VoIP network 

• Identify other standards that support communications transmission within a 
VoIP network 
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Standards and Organizations 

Standards are extremely important when transmitting communications 
throughout an IP network. The basis of a network is allowing equipment and 
applications to transport, recognize, process, and respond to user requests for 
information. Some advantages of standards are: 

• Interoperability: Equipment can interconnect and operate properly 

• Competition: Manufacturers can focus on their respective product, 
equipment, or application strengths 

• Ready Market: Development of equipment that can function in an open 
network 

• Obsolete Technology: Users are protected from the introduction of 
technology that can become obsolete in a short period of time 
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Standards Organizations 

Within the communications industry, several organizations exist that help 

determine and define standards. Some key players are: 

• American National Standards Institute (ANSI): Authorizes industry 
organizations to develop actual technical standards; T-l committee 
develops all network provider standards (www.ansi.org) 

• International Standards Organization (ISO): Developed the ISO model, 
JPEG, MPEG, and many international quality standards (www.iso.ch) 

• International Telecommunications Union (ITU): Develops standards 
that allow international network providers to interconnect (www.itu.int) 

• European Telecommunications Standards Institute (ETSI): Responds 
to member needs for standardization (www.etsi.org) 

• Institute of Electrical and Electronic Engineers (IEEE): Develops 
standards for the electrical industry; developed 802.X LAN/MAN 
standards (www.ieee.org) 

• Electronic Industries Alliance (EIA): Dedicated to consumer electronic 
standards; sanctioned by ANSI; a key player in HDTV and multimedia 
standards (www.eia.org) 

• Information Infrastructure Standards Panel (IISP): Promotes, 
accelerates, and coordinates standards for a National Information 
Infrastructure, the “Information Superhighway”; sponsored by ANSI 

• Telecommunications Industry Association (TIA): The official standards 
body for cellular/PCS; heavily involved with defining VoIP standards 
(www.tiaonline.org) 

• Internet Engineering Task Force (IETF): Provides Internet standards 
(www.ietf.org) 

Two key players in the IP network world are the ITU and the IETF. The 

organization and recommendations they provide affect transport of 

information. 
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International Telecommunications Union 



Standardization 


Telecom 

Development 

(ITU-D) 


The ITU is an international organization that supports the determination of 
standards used in a voice, video, and data network. However, many standards 
are designed and recommended by an organization outside of ITU, such as 
ANSI, and later incorporated into ITU-T recommendations, such as V.28. 

Figure 1: International Telecommunications Union Home Page 
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B Welcome to the International Telecommunication Union 


The ITU , headquartered in Geneva, Switzerland is an 
international organization within the United Nations System 
where governments and the private sector coordinate global 
telecom networks and services. 

1 ITU Newsroom - ITU News magazine 

■ ITU Publications 

The ITU is the leading publisher of telecommunication 
technology, regulatory and standards information. Many 
publications can be purchased through our Electronic 
Bookshop or the ITU Publications Online subscription 
service. 
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The ITU actually consists of several committees dedicated to a specific aspect 
of the industry. Within each committee, a study group is formed, which then 
releases recommendations for standards. The standards are issued by a letter 
(V, X, G, and so forth) representing the study group assigned to a specific 
activity followed by a sequence number. The specific ITU committees are: 

• ITU-D: Telecom Development 

• ITU-R: Radiocommunication Sector 

• ITU-T: Telecom Standardization 

Within the ITU-T, there are 15 study groups that prepare recommendations for 
standards: 

• Group 2: Network Operation and Study Group QoS 

• Group 3: Tariff Accounting Principles 

• Group 4: Network Maintenance Practices 

• Group 5: Electromagnetic Environment Effects 

• Group 6: Outside Plant (cables, poles and vaults) 

• Group 7: Data Networks and Open Systems; recommendations in X. 
format 

• Group 9: TV Video and Sound Transmission; recommendations in H. 
format 

• Group 10: Languages for Telecommunications Applications 

• Group 11: Switching and Signaling (SS7); recommendations in Q. format 

• Group 12: End-to-End Transmission Performance 

• Group 13: General Network Aspects (ISDN); recommendations in I. 
format 

• Group 15: Transmission Systems (DS-1; SONET); recommendations in 
G. format 

• Group 16: Modem, Data, Telegraph; recommendations in V. format 

• Special Study Group: International Mobile Telecommunications (IMT) 
2000 and beyond 

The ITU releases Recommendations that generally become network standards 
as the recommendations are accepted and implemented by manufacturers, 
providers, and suppliers. 
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Internet Engineering Task Force 

The function of the IETF is to develop and review specifications intended as 
Internet Standards. Its tasks are accomplished through the use of more than 100 
working groups, organized by topic into several areas, such as routing, 
transport, and security. IETF membership is comprised of network designers, 
operators, vendors, and researchers. 


Figure 2: Internet Engineering Task Force Home Page 
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The IETF is comprised of: 

• Internet Engineering Steering Group (IESG): Comprised of Area 
Directors that manage IETF working groups 

• Internet Architecture Board (IAB): Provides architectural oversight and 
arbitrates appeals 

The IETF releases Request for Comment (RFC) documents that can range 
from an official Internet standardized protocol specification to research results. 
Various organizations with common interests form a “Working Group” (WG). 

A WG generates RFCs and submits them to the Internet community for 
comment and suggestion. Once an RFC reaches its final draft, the proposed 
standard, and generally agreed-upon idea, is documented, published, and made 
public by the IESG on behalf of the IETF. 

Over time, the RFCs are refined. When a final document is created and agreed 
upon by the WG and the Internet community, a vote is taken. After a six-month 
waiting period, the RFC becomes ratified and becomes the standard. Once the 
official vote is taken, most vendors begin to develop product. However, not all 
RFCs become Internet Standards. A number of RFCs created do not affect 
transporting of information and are informational RFCs. 


Notes 
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Signaling Protocols 

Signaling protocols initiate and control communications. The type of protocol 
and the technology involved to support it is dependent on the type of 
communications and applications involved, such as voice, video, or data. The 
signaling protocols that will be addressed are: 

• H.323 

• Session Initiation Protocol (SIP) 

• Media Gateway Control Protocol (MGCP) 

• MEGACO/H.248 -- ? £ /j_ T \J 
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H.323 


H.323 is a suite of protocols that initially supported only videoconferencing 
systems over LAN/WAN topologies and protocols. However, H.323 V2 has 
evolved into a packet-based signaling standard that provides a foundation for 
audio, video, and data communications across IP-based networks, including 
the Internet. H.323 is network, platform, and application independent, allowing 
any H.323 compliant device to interoperate with any other. Though H.323 does 
2_ ^not provide a guaranteed QoS, users can communicate without concern for 
compatibility. H.323 supports both stand-alone devices and embedded personal 
computer technology, in addition to point-to-point and multipoint 
conferencing. H.323 also addresses: 

• Call control 

• Multimedia management 

• Bandwidth management 

• Interfaces between LANs and other H.323 non-compliant endpoints 


Table 1: H.323 V2 


Component 

Description 

Network 

Non-guaranteed bandwidth packet switched 
networks, (Ethernet) 

Video 

H.261 


H.263 

Audio 

G.711 


G.722 


G.728 


G.723 


G.729 

Multiplexing 

H.225 

Control 

H.245 

Multipoint 

H.323 

Security 

H.235 

Data 

T.120 

Comm. Interface 

TCP/IP 



Note: G.XXX compression algorithms are existing ITU standards 
incorporated into the H.323 protocol suite. 
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H.323 incorporates support for various CODECs or speech compression 
techniques for digitizing and compressing speech signals derived from the 
existing ITU standards. These CODECs are chosen by the network 
administrator and affect factors, such as speech quality, bit rate, computer 
power, and signal delay. The supported codecs are: 

• G.711: Used for voice transmission over digital telephone sets on a PBX 
and ISDN channel 

Is the standard against which all other encoding algorithms are 
compared 

Uses an encoding algorithm called Pulse Code Modulation (PCM) that 
encodes voice into digital signals that is transmitted at a rate of 64 Kbps 

• G.722: Uses a compression algorithm that encodes voice into a digital 
signal that transmits voice at a rate of up to 32 Kbps 

• G.728: Recommended for low-bit-rate ISDN video telephony 

Uses a compression algorithm known as Low Delay-Code Excited 
Linear Prediction (LD-CELP) that encodes voice into a digital signal 
that transmits voice at a rate of 16 Kbps 

• G.723.1: Uses a compression algorithm that encodes voice into a digital 
signal that transmits at a low rate of 5.3 or 6.3 Kbps 

3> ] • G.729: Default specification for Internet Telephony 

- Uses a compression algorithm known as Conjugate Structure-Algebraic 
Code Excited Linear Prediction (CS-ACELP) that encodes voice into a 
digital signal that transmits at a rate of 8 Kbps 

Utilizes silence suppression or Voice Activity Detection (VAD) in the 
transmission of voice communications which can further reduce 
bandwidth requirements to as low as 4 Kbps 


Notes 



Issue 2.0 January 6, 2003 


VoIP Standardization and Signaling Protocols 





Page 12 of 48 


Figure 3: H.323-based Software Supports VoIP PC Calls 



Sound Card 
Microphone or Headset 
Voice packetizing (H.323) software 


Sound Card 
Microphone or Headset 
Voice packetizing (H.323) software 


Notes 



VoIP Standardization and Signaling Protocols 


Issue 2.0 January 6, 2003 











Components of H.323 

H.323 is a flexible standard that can be applied to voice-only handsets and full 
multimedia video-conferencing stations. H.323 has broad industry support, 
which has established H.323 as the standard for transporting audio and video 
communications in an IP packet-based network. H.323 consists of four key 
components for an H.323-based communications system: Gateway, 
Gatekeeper, Multipoint Control Unit (MCU), and Terminals. 

Figure 4: H.323 Architecture Overview 



Note: A gatekeeper zone is comprised of terminals, gateways, and MCUs 
managed by a single gatekeeper. 
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Gateways 

Some characteristics of gateways are: 

• Optional in an H.323 conference 

• Bridge H.323 conferences to other networks, communications protocols, 
and multimedia formats 

• Not required if connection between two H.323 devices on the same LAN or 
in networks where there are no non-H.323 devices utilized 

• Connect divergent networks by translating between signaling protocols for 
call setup, teardown, and converting media formats between dissimilar 
networks, such as Ethernet and ISDN 
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Gatekeepers 

Without Gatekeepers, each device must be manually configured for inter¬ 
device communications. Other characteristics of gatekeepers are: 

• Provide a centralized service to which all H.323 devices register 

• Perform address translation and bandwidth management on an IP network 

• Map LAN aliases to IP address, provide address lookups, and maintain 
E.164 addresses, when needed 

• Exercise call control functions to minimize the number of H.323 
connections and the total bandwidth used in an H.323 zone 

• Provide accounting, billing, and chargeback capabilities 


Table 2: Required Gatekeeper Functions 


Gatekeeper Function 


Address Translation 


Admissions Control 


Bandwidth Control 


Zone Management 


Description 

Provides for translation of alias address, such as URL, to 
transport address, such as IP; uses registration and update 
messages to build translation tables 

Provides LAN access authorization, utilizing Admission 
Request, Confirmation, and Reject (ARQ/AC£/ARJ) messages 
Access can be based on call authorization, bandwidth, or other 
criteria; Admissions Control can also be a null function 
admitting all requests 

Supports Bandwidth Request, Confirmation, and Reject (BRQ/ 
BCF/BRJ) messages that can be utilized in bandwidth 
management; Bandwidth management can also be a null 
function accepting all bandwidth change requests 

Provides above functions for terminals, MCUs, and Gateways 
registered within its management Zone 
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Table 3: Optional Gatekeeper Functions 


Gatekeeper Function 

Description 

Call Control Signaling 

Can process Q.931 call control signals in point-to-point 
conference and can send Q.931 signals directly to 
endpoints 

Call Authorization 

Criteria can reject call from a terminal based on Q.931 

Rejection can include, but is not limited to, restricted 
access to/from particular terminals or Gateways or 
restricted access during certain periods of time 

Criteria for authorization pass or fail is outside the 
capability of H.323 

Bandwidth Management 

If sufficient bandwidth is not available or if a terminal 
requests additional bandwidth, can reject call 

Criteria for determining available bandwidth is outside the 
capability of H.323 

Call Management 

Maintains a list of ongoing H.323 calls to determine 
whether a called terminal is busy or to provide information 
for Bandwidth Management function 


Notes 
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Multipoint Control Units 

Characteristics of MCUs are: 

• Support conferences between three or more endpoints 

• Consist of a required Multipoint Controller (MC) and zero or more 
Multipoint Processors (MPs) 

MC is software that performs H.245 negotiations between all devices to 
determine common audio and video processing capabilities 
MP provides both a hardware and software function that encodes and 
routes audio, video, and data streams between device endpoints; can 
co-exist on same device with Gatekeeper software 






Notes 



Issue 2.0 January 6, 2003 


VoIP Standardization and Signaling Protocols 








Page 18 of 48 


Terminals 

Terminals are considered client endpoints on the network. All terminals must 
support voice communications. Video and data support is optional. 


Figure 5: H.323 Terminal Equipment 
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Role of the Multipoint Control Unit 

The MCU plays a pivotal role in the establishment of conference calls and the 
downloading of information to multiple sites. There are two ways this function 
can be accomplished: 

• Multicast (Decentralized): 

Occurs directly from an H.323 device 
Ensures each device is conforming to standards 
Uses negotiations conducted by the MC 

Reduces bandwidth requirements, since all endpoints in the multicast 
group receive a single data stream 

• Unicast (Centralized): Uses transcoding or translating protocols of 
various CODECS and rates, or enforcement of common set of protocols 
and rates; is provided by centralized MCU 

MCU accepts audio stream from the conferees, encodes it into a common 
signaling format, and regenerates this signal back out to all participants. 

Sends multiple point-to-point transmission, yet is considered inefficient, 
because packets are replicated throughout the network 


Figure 6: Multicast and Unicast Conferencing 
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H.323 Protocols 

utilizes various protocols to support communications between endpoints, such 
as terminals. Gateways, and MCUs. These protocols are: 

• H.225: 

Establishes the first connection, typically to port 1720 

Performs registration, admission control, bandwidth changes, status, 
and disconnect procedures between endpoints and gatekeepers 

Utilizes the Q.931 signaling method 

Utilizes Fast Connect or Fast Call Setup, which carries the H.245 
signaling information within the H.225 message 

• H.245: 

Negotiates audio and video codecs to ensure disagreements are 
efficiently settled 

Transmits DTMF codes, lamp indicator control, and other control 
signaling information required by an H.323 device, in addition to 
opening and closing media channels 

• H.325: Used for security 



* 
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• RTP/RTCP: 

RTP utilizes User Datagram Protocol (UDP) and provides end-to-end 
delivery services of real-time audio and video through payload-type 
identification, sequence numbering, timestamping, and delivery 
monitoring 

RTCP provides control services and feedback on the quality of the data 
distribution, and is intended to typically be utilized as a troubleshooting 
tool 

• Q.931: Defines and specifies call signaling and call setup 
acknowledgements and requirements 

Figure 7: H.323 Protocols 





Notes 



Issue 2.0 January 6, 2003 


VoIP Standardization and Signaling Protocols 







Page 22 of 48 


H.323 Major Operations 

While transporting information, H.323 proceeds in phases from endpoint to 
endpoint. Different scenarios of call setup can occur, based on whether a 
Gatekeeper is involved in the communications process. Following is an 
example of major H.323 phases, which include a Gatekeeper. 

Figure 8: Call Setup Operations of H.323 
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Explanation of the H.323 Call Setup Operation 

Following is a description of the call setup operation: 
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Endpoint A sends the RAS ARQ message on the RAS channel to the 
Gatekeeper for registration. Endpoint A requests the use of direct call 
signaling 


2. Gatekeeper confirms the admission of Endpoint A by sending ACF to 
Endpoint A. Gatekeeper indicates in ACF that Endpoint A can use direct 
call signaling 

3. Endpoint A sends an H.225 call signaling Setup message to Endpoint B to 
request a connection 

4. Endpoint B responds with H.225 Call Proceeding message to Endpoint A 

5. Endpoint B has to register with the Gatekeeper and sends an RAS ARQ 
message to the Gatekeeper on the RAS channel 

6. Gatekeeper confirms the registration by sending an RAS ACF message to 
Endpoint B 

7. Endpoint B alerts Endpoint A of the connection establishment by sending 
an H.225 Alerting message 

8. Endpoint B confirms the connection establishment by sending an H.225 
Connect message to Endpoint A, and the call is established 
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Interoperability of H.323 

Although H.323 provides a common set of procedures for performing client 
registration, call setup, call teardowns, and other functions, interoperability 
issues arise due to the different interpretations of the standard by 
manufacturers and vendors. This often leads to problems in establishing 
communications between different manufacturers’ equipment in the early 
stages of development. To ensure vendor and equipment H.323 compliance, 
interoperability testing is sponsored by International Multimedia 
Teleconferencing Consortium (IMTC). The mission of IMTC is to assist in the 
delivery of standards-based and rapid development of conferencing products 
and services. In addition, IMTC promotes the importance of industry-wide 
interoperability. 



Notes 
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Well-known Ports 

Within networking, port numbers are defined and tend to be reserved for 
frequently used, higher level processes. Regardless of which customer network 
or which endpoint, these ports typically remain the same. 

Some examples of well-known ports are: 

• 25: SMTP 

• 80: Web 

• 110: POP 

• 1718: Gatekeeper discovery 

• 1719: Registration with the Gatekeeper 

• 1720: H.225 destination 
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Session Initiation Protocol 

Initially created for the distribution of multimedia content, Session Initiation 
Protocol (SIP) was designed to be scalable and to utilize existing protocol tools 
that integrated well with other IP applications, such as email or WWW. 
Defined by IETF RFC 2543, interoperability is another key goal of SIP. 

Key functions of SIP are: 

• Supports interactive communications between users 

• Handles session initiation, termination, and modification 

• Describes session content through the use of Multipurpose Internet Mail 
Extensions (MIME) 

• Determines the location, or presence, of the user within the network 

• Supports multicast, unicast, a mesh of unicast sessions, or a combination of 
unicast and multicast: 

Unicast: Communications only between a single sender and a receiver 
over a network 

Multicast: Communications between a single sender and multiple 
receivers 

Anycast: More commonly referred to as a broadcast; Provides 
communications between a single sender and all devices on the same 
subnet 

• Supports mobile users 


Notes 
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Components of Session Initiation Protocol 

Based on a client-server model architecture, SIP components consist of the 
Server, the Registrar, the User Agent Server, and the User Agent. 

Server 

The Server accepts request messages from the client and forwards accordingly; 
sends back responses to the client’s requests. 

• Proxy Server: 

- Functions as a server and a client in order to make requests on behalf of 
other clients 

- Supports requests locally or forwards on to other servers 

- Interprets and may rewrite a SIP request message prior to forwarding to 
another server or to user agent 

• Redirect Server: 

- Accepts a SIP request, maps the address in the request to a new 
address, and returns the appropriate message to the client 

- Does not “forward” SIP requests to other servers and does not accept 
calls 

Registrar 

The Registar performs these functions: 

• Accepts REGISTER request and is typically co-located with a proxy or 
redirect server; may offer location services 

• Registers SIP parties in a SIP domain that is within the administrative 
entity for a SIP provider 
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User Agent Server 

The User Agent Server (UAS) contacts the user when a SIP request is received 
and returns an appropriate response on behalf of the user. 

User Agent 

The User Agent (UA) contains both a User Agent Client (UAC) and User 
Agent Server (UAS). 

Figure 9: Session Initiation Protocol Architecture Overview 
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Session Initiation Protocol 

SIP is based on a request-response model or INVITE to a Uniform Resource 
Locator (URL), or Internet address, for establishment of a session. The 
protocols that can be utilized to establish a session are: Session Description 
Protocol (SDP), Session Announcement Protocol (SAP), and Real-Time 
Streaming Protocol (RTSP). 

Session Description Protocol 

The SDP performs these functions: 

• Conveys setup and media information pertaining to session recipients 

• Conveys sufficient information to SIP entities to allow them to join and 
participate in the session 

Session information includes the following: 

• Purpose of the session 

• Name of session 

• Time of the session 

• Media type pertaining to the session, such as video and audio 

• Formatted information for the video or audio session 

• Pertinent IP addresses and port numbers for the session 

Session Announcement Protocol 

The SAP is an IETF experimental standard. The SAP performs these functions: 

• Delivers SDP packets using multicasting where participants are not known 
in advance; a multicast session is announced by sending multicast packets 
to a well-known multicast group carrying an SDP description of the session 
to occur 

• Creates, modifies, and terminates sessions 

• Contains SDP as payload 

• Compares to a television schedule 

• Announces a conference session by periodically multicasting an 
announcement packet to a well known multicast address and port 

Real-Time Streaming Protocol 

The RTSP supports the control of delivered multimedia stream to include 
pause, fast forward, reverse, and absolute positioning within the media stream, 
recording, and device control. 
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Advantages of Session Initiation Protocol 

There are several advantages to SIP that are ideal to a VoIP network. They are: 

• Integration: Works well with various applications utilizing URLs, 
supporting MIME, and carrying images, MP3s, and Java applets, in 
addition to utilizing email routing mechanisms 

• Scalability: Supports several types of proxy servers 

• Extensibility: Consists of several mechanisms for extension of protocol 

• Flexibility: 

Allows utilization of the protocol, as needed 

Does not dictate architecture, usage patterns, or deployment scenarios, 
but rather provides a framework within which it operates 

Relies on other protocols and techniques to provide QoS 

- May not send INVITE over the same networks that voice packets travel 
Remains totally independent of the voice path 

- Allows a caller to be routed through an H.323 gateway for processing 

• Mobility: 

- Supports personal mobility, allowing networks to identify end users 
regardless of location on the network 

- Allows end users the ability to originate and receive calls and access 
services on any network device, such as PC, laptop, or IP phone, 
regardless of location 


Notes 
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Disadvantages of Session Initiation Protocol 

In addition to the advantages, there are disadvantages to SIP. They are: 

• Increasing shortage of IP v4 numbers 

• Growing use of NATs may prevent private Internet endpoint from receiving 
INVITE 

• Transporting media to an address through firewalls can cause removal of 
information, unless a rule is established to allow media to pass through 
proxy servers 
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Session Initiation Protocol Major Operations 

SIP operations follow a different set of procedures when inviting a participant 
to a session as compared to an H.323 Call Setup. There can be instances when 
the INVITE has to be redirected and a User Agent located. This is one of the 
valuable advantages of this protocol. Following is a example of such an 
INVITE, which has to be redirected to locate an invited participant. 

Figure 10: Session Initiation Protocol Major Operations 


wta.com 



SIP Client 
(User Agent 

d<od(i^et.^ v ' afS ^ ,cow 


Use the following information to understand the flow of information. 


1 . 

2 . 

3. 

4. 

5. 

6. 

7. 

8 . 

9-10, 11, 12 

13. 

14. 


msafin@atp.com sends a SIP INVITE message to atp.com proxy to place a 
call to arod@wta.com 

atp proxy forwards request to wta.com server 

wta server determines arod is temporarily at sponsor.comwta.com server 
sends redirect to atp.com proxy to try sponsor.com 

atp proxy sends INVITE to arod@sponsor.com 

sponsor.com server consults its database 

sponsor.com determines arod is located at get.sponsor.com 

sponsor.com sends new URL to arod@get.sponsor.com and sends INVITE 

to get.sponsor.com proxy 

get.sponsor proxy forwards INVITE to arod’s PC after SIP used REGISTER 
action to ensure location of arod through an address binding procedure; arod 
responds to request 

response is forwarded back through proxies to original caller 
ACK is sent 

Session is established and media is transmitted 
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Session initiation Protocol Requests and Response Types 



Various acknowledgements and responses occur during a SIP Request between 
User Agents (UA), SIP Proxy Servers, SIP Redirect Servers, Registrars, and 
User Agent Servers (UAS). It is important to know the SIP Requests, in 
addition to some of the key SIP Response Types, that occur during the call 
setup process. SIP Requests are: 

• INVITE: Starts a session 

• ACK: Confirms User Agent has received final response to an INVITE 


• BYE: UA uses BYE to tell server to release the call 


• CANCEL: Cancels pending request, but not the completed request 

• OPTIONS: Only requests information about capabilities 

• REGISTER: Provides user’s location to a SIP server 


There are a number of SIP Response Types to indicate the progress of a Call 
Setup. Following are some of the key Response Types: 

• lxx Trying 

180 Ringing 

) • 2xx Successful connection 

• 3xx Redirection 

- 305 Use Proxy 

• 4xx Request Failure 

- 407 Proxy Authentication Required 

- 415 Unsupported Media Type 

483 Too Many Hops 

484 Address Incomplete 

- 486 Busy Here 

• 5xx Server Failure 

- 502 Bad Gateway 

- 504 Gateway Time-out 
505 Version Not Supported 

• 6xx Global Failures 

600 Busy Everywhere 

- 603 Decline 
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Session Initiation Protocol INVITE 

A SIP INVITE is required in order to set up a Media session. The information 
contained in the INVITE will be different based on the type of Media session, 
message body length, and various other data. Following is an example of the 
INVITE sent by msafm@atp.com to arod@wta.com. 


Figure 11: Session Initiation Protocol INVITE 


INVITE siD: arod@wta.com SIP/2.0 

SIP URL of the called party 

Via: SIP/2.0/UDP msafin.atp.com 

Indicates path taken by the request 

From: Marat <sip:msafin@atp.com> 

Initiator of request 

To: Andy <sip:arod@wta.com> 

Recipient of request 

Call-ID: 1113244434@atD.com 

Uniquely ID s a particular invitation 

Cseq: 1 Invite 

Command Sequence - Uniquely ID’s a 
request within a Call-ID 

Subject: Your tennis game 

Nature of the call 

Cont-Type: application/SDP 

Indicates the Media type in message 

V=0 

Protocol version 

0=Marat 76329381938 IN IP4 192.168.3.2 

User, session ID, network type, 

Address 

S=marat203 

Session name 

C-IN IP4 192.168.3.2 

Connection info 

M-audio 5004 RTP/AVP 0 12 18 

Media name, port address, Codec 
options available from client 


Notes 



VoIP Standardization and Signaling Protocols 


Issue 2.0 January 6, 2003 






Session Initiation Protocol and Mobility 

As stated earlier, an advantage of SIP is the ability to support mobility, whether 
terminal or personal. Terminal mobility occurs when terminals move between 
subnetworks supported by Global System for Mobile Communications (GSM) 
and wireless LAN technology. This technology requires mobile hosts to inform 
their home proxy servers of their new locations using the REGISTER 
procedure. In-progress mobile calls also need to inform their home proxy 
servers of their constantly changing location through the REINVITE 
procedure. 

Current issues regarding mobility are: 

• Triangular routing increases delay v 

• Tunnelling increases bandwidth consumption 




Notes 
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H.323 Versus Session Initiation Protocol 

There are distinct differences between the ITU-T H.323 and the IETF SIP, and 
how they support VoIP. For instance, H.323 specifies a complete, vertically 
integrated system, while SIP can be built utilizing a variety of architectures and 
protocols. Following are additional differences between the two protocols: 


Table 4: H.323 Versus Session Initiation Protocol 


Aspect 

SIP 

H.323 

Origin 

Networking community (IETF) 

Telecom community (ITU) 

Architecture 

Element 

Stack 

Encoding 

HTTP-like 

ASN.l 

Network Intelligence and Services 

Provided by Servers (Proxy, 
Redirect, Registrar) 

Provided by Gatekeepers 

Clients 

Intelligent 

Intelligent 

Emphasis 

Multimedia, multicast, telephony 

Telephony, video, whiteboard, 
document sharing 

Transport 

Mostly UDP 

V1=TCP; V2=UDP 

Address 

SIP URLs 

Aliases 

Service 


Call Hold 

Yes 

Yes 

Call Transfer 

Yes 

Yes 

Call Forward 

Yes 

Yes 

Call Waiting 

Yes 

Yes 

Third-Party call 

Yes 

No 

Conference 

Yes 

Yes 

Click-to-Dial 

Yes 

Yes 

Capability Exchange 

Yes 

Yes 

QoS 

■ *&••••»« - . • — * • ■ •• *. - ■ 

Call Setup Delay 

1.5 rt 

2.5 rt 

Packet Loss Recovery 

Yes 

Yes 

Loop Detection 

Via Hops 

Path Value 

Fault Tolerance 

Yes 

Backup 
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Other Signaling Protocols 

There are two relatively low-level device-control protocols that instruct a 
Media Gateway to merge streams coming from an external cell or packet 
network onto a cell or packet stream, such as RTP. In addition, these protocols 
also provide call setup and clear voice or video calls in a packet network, 
though the tasks they follow are different. These device-control protocols are: 

• Media Gateway Control Protocol (MGCP) 

• MEGACO/H.248 

In reality, due to a combination of resources and agreements between the ITU, 
ITEF, and the ETSI, MEGACO is the current standard being adopted and 
developed. 


Figure 13: Gateway Protocol History 
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Media Gateway Control Protocol 

IEFT RPC 2705 defines the scope of MGCP within the IP network. MGCP is 
actually a merger of the Internet Protocol Device Control (EPDC) and Signal 
Gateway Control Protocol (SGCP). 

IPDC is a suite of protocols that can, individually or together, perform 
connection control, media control, and signalling transports between the 
circuit-switched network and the Internet. IPDC was developed by a 
consortium formed by Level 3 Communications. 

SGCP is a UDP-based protocol designed to address the concept of a network 
that combined voice and data on a single packet-switched IP network operating 
at a low level. SGCP was developed by Bellcore, now called Telcordia 
Technologies, and Cisco Systems. 

MGCP resembles IETF SIP in its functionality. Both IPDC and SGCP 
addressed the SS7/VoIP issues offering centralized control of VoIP gateways, 
remote access concentrators, central office switches, and tandem switches. The 
functionality is similar to the relationship between the SS7 and the PSTN. The 
differences between the IPDC and SGCP were a result of differing 
manufacturers and vendors involved in defining the standards and how they 
approached the goals each utilized. MGCP supports audio communications. 
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Role of Media Gateway Control Protocol 

The role of MGCP is: 

• Decomposes a Telephony Gateway into a controlling signaling component 
and a controlled media component 

• Instructs the controlled media component to send and receive media from 
specific addresses and to generate tones 

• Allows configuration modification 

• Ensures the controlled entity reports back to the controller, for instance, 
when DTMF digits and tones are detected 

• Supports an IP phone, with the controller software acting as a PBX to 
provide features capabilities and call setup through the use of a SIP 
INVITE to connect the call 


Figure 14: Decomposed Gateway 



Note: Decomposed Gateway functionally can exist on a single device. 
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Components of Media Gateway Control Protocol 

MGCP consists of two key components. They are: 

• Call Agent: 

Signalling and call processing, and the Gateway 
Web-based protocol 

Software-based program known as a Gateway Controller 

• Gateways: 

- Network elements that provide audio signal to data packet conversion, 
which is transmitted on telephony circuitry, the Internet, or other packet 
networks 

Endpoint-to-packet network or endpoint-to-endpoint connection in the 
same gateway 


Figure 15: MGCP Architecture Overview 





Notes 
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MEGACO 

MEGACO is the IETF version of ITU H.248 from the H.323 standards 
protocol suite, and is the official international standard for decomposed 
gateway architectures. In addition, MEGACO is the successor to MGCP. Some 
of the functionalities of MGCP have been incorporated into MEGACO. 
MEGACO is an ASCII-based protocol and considered similar to HTTP. 

H.248, from the H.323 standards protocol suite, also utilizes the ASCII-based 
protocol, but encodes utilizing the ASN.l command/response format. 
MEGACO supports multimedia and has more capabilities for various types of 
gateways. 

MEGACO also supports call processing, using two abstraction concepts for its 
operations: Terminations and Contexts. These two concepts are used to 
manage calls and define call states. In addition, MEGACO: 

• Allows transactions that consist of several actions and commands 

• Provides high availability in the event of equipment or network failures 

! • Utilizes easy-to-use tools to support the events, signals, and statistics 
9 ) necessary to control and manage the Media Gateway (MG) 
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Components of MEGACO 

The key to MEGACO and its functionality is the use of its components. They 
are: 

• Media Gateway Control (MGC): 

Provides central point of intelligence for the Media Gateways 
Controls one or more MGs 

Communicates to Media Gateway and Signaling Gateway via TCP/IP 

• Media Gateway (MG): 

- Controls and processes media streams between networks 

Functions primarily as a slave to execute commands from the MGC 

• Signaling Gateway (SG): 

Provides interoperability between the legacy SS7 and the newly- 
defined Stream Control Transmission Protocol (SCTP) 

Acts as signaling server created for the PSTN 


Figure 16: MEGACO Architecture Overview 
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Practice 

Answer the following questions. 

1. Within the H.323 protocol, the standard that defines control parameters is 


a. H.261 

b. G.729 

c. H.225 

d. ) H.245 

2. A key advantage of utilizing H.323 is that H.323 provides a guaranteed 
QoS. 

a. True 

b. False 

3. When programming a codec in an H.323 device for voice transmission on 

an IP WAN network,_is the assigned default. 

a. G.711 

b. G.723.1 

c. G.728 

d. G.729 

4. The first major operation in establishing an H.323 call setup is_ 


: a - 

ARQ 

b. 

ACF 

c. 

ARJ 

d. 

ACK 
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5. A key function of the SIP Redirect Server is the ability to_. 

a. Forward SIP requests to other servers 

b. Accept REGISTER requests 

c. Offer location services 

d. \Map an address in the request to a new address, returning the message 

to the client 

6. The first major operation in SIP call setup is_. 

a. DISCOVER 

b. REQUEST 

c. ACK 

d. INVITE 

7. A SIP Response Type indicating a successful connection is_. 

a. lxx 
^ b. 2xx 

c. 3xx 

d. 4xx 

8. The role of MGCP is to_. 

a. ) Decompose a Telephony Gateway into controlling signaling and 

controlled media components 

b. Provide high availability in the event of equipment failures 

c. Communicate to the MG and SG via TCP/IP 

d. Support Proxy Servers 

9. A function of MEGACO MGC is to provide control and intelligence to the 
MG. 

ya. True 
b. False 
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Answers to Practice 

See your instructor for the answers to the Practice. 


Notes 
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Summary 

In this lesson, you learned that VoIP standards are determined by organizations 
attempting to encourage compliance by manufacturers, vendors, and users to 
ensure a healthy and robust network. In addition, we reviewed the various 
signaling protocols used by the various manufacturers and vendors in 
processing information over the IP packet-based network. We also identified 
the capabilities of interworking between various signaling protocols. 
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Network Assessment 


Introduction 

To successfully deploy a Voice over IP (VoIP) solution in an existing network, 
planning is vital. Some key factors to consider are: 

• Is the data network ready for VoIP traffic? 

• What level of voice quality does the customer expect? 

• How will VoIP deployment impact the existing traffic flow? 

• What type of VoIP solution is the customer deploying? For example: IP 
terminals, IP trunks, or both? 

Without adequate planning prior to VoIP deployment, the customer can 
experience poor voice quality, network traffic bottlenecks, or the inability to 
provide the same level of service to all sites. This can result in customer 
dissatisfaction and additional time and expense to correct problem conditions. 

An effective network assessment is designed to identify potential issues prior 
to deployment, allowing time to make recommendations and to modify the 
existing data network infrastructure so the VoIP network meets the customer’s 
expectations and needs. 

This lesson guides you through the network assessment process. 


Notes 



• # 


© © 
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Objective 

Given this module and the instructor’s presentation, you will be able to 

complete these tasks: 

• Define the recommended VoIP network assessment process and areas to 
prepare for VoIP deployment (such as: link types and speeds, peak delay, 
packet loss, and LAN/WAN platforms) to prepare for VoIP deployment 

• Develop customer recommendations for network improvements based on 
sample network assessment scenarios in preparation for VoIP deployment 

• Identify tools available for use during the network assessment process, 
such as: 

Sniffer Pro (sometimes known as Sniffer Portable) 

Net IQ Chariot 
NetlQ Qcheck 
NetlQ VoIP Assessor 
- NetAlly 

Multi Router Traffic Grapher 
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Network Assessment Process Overview 


Following is an overview of the network assessment process. 


Figure 1: Network Assessment Process Overview 



Data and Voice Considerations 

- Customer interview - Call Detail Records 

- Network diagrams - Numbering Plan 


Acceptable Traffic Value 

-E-Model 

-R-Factor 

Power Tools 

- Sniffer™ Pro 

- NetlQ Chariot 

- NetlQ Qcheck 


Report Outputs 

- Bandwidth 

- Traffic flow 

- Capacity 

Implementation 

- Pilot 


- Map R-Value to MOS 

- Identify acceptable value 


- NetlQ VoIP Assessor 

- NetAlly (Viola Network) 

- Multi Router Traffic Grapher 


- Latency, packet loss, and 
throughput 


- Implementation 




Notes 
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Perform Readiness Audit 

The first step is a readiness audit. During this phase, collect information about 
the existing data and voice networks. You can obtain this information through 
customer interviews, diagrams, and system reports. Later, you will use this 
information as a baseline to determine if any modifications are required to 
insure a successful VoIP deployment. 

Data Network Considerations 

Important data network considerations during the readiness audit are: 

• Links: 

- Types: Point-to-Point Protocol (PPP), Frame Relay, Asynchronous 
Transfer Mode (ATM), and Ethernet 

Speeds 

Utilization 

Hardware 

• Quality of Service (QoS): 

Bandwidth 
Network availability 
Delay 
Loss 

• Protocols and Security: 

Firewalls 

Network Address Translations (NATs) 

Secure Virtual Private Networks (VPNs) 

• Routing protocols 

• Traffic flow 
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Link Types 

Point-to-Point Links 

Serial Point-to-Point links use Point-to-Point Protocol (PPP) to transport data 
between two hosts over a dedicated link. PPP links provide the most control for 
QoS, as they are direct point-to-point links and provide dedicated bandwidth. 
However, they can be more costly. 

Frame Relay 

Frame Relay is more cost effective than PPP. However, it is based on a publicly 
shared model. Once the transmission enters the provider’s WAN, delivery is 
considered best-effort. This means that the provider does not guarantee any 
priority over other transmissions. A Committed Information Rate (CIR) 
provides a higher level of assurance. However, unless the CIR is set for the 
total peak traffic, there is still a chance that traffic that exceeds the CIR will be 
marked Discard Eligible (DE) and dropped by the provider. 

Asynchronous Transfer Mode 

Asynchronous Transfer Mode (ATM) is similar to Frame Relay, in that it is 
cost effective, but there is no guarantee of prioritization unless the customer 
has purchased a Constant Bit Rate (CBR) service. The CBR provides a 
dedicated channel with a fixed bandwidth, based on the needs of the 
application. However, with ATM there is an additional overhead for header 
information associated with VoIP transmissions. This impacts how the frame is 
segmented and the CODEC used. 

Ethernet 802.3 

Ethernet 802.3 is the IEEE standard for Ethernet networks using the CSMA/ 
CD access method on a bus topology LAN. Ethernet is a LAN transport 
protocol developed by Xerox Corporation in cooperation with Digital 
Equipment Company and Intel in the late 1970s. Ethernet is a network protocol 
standard that specifies how data is placed on and retrieved from a common 
transmission medium. 
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Link Types and Speeds 

Remember, it is important to know the link types used because this impacts the 
overhead of the packet. In addition to link types, speed is important because it 
can introduce delay. 

Figure 3: Link Types and Speeds 


• Types 

- Point-to-Point Protocol (PPP) 

- Frame Relay 

-Asynchronous Transfer Mode (ATM) 

- Ethernet 

• Speeds 

- Can introduce delay 

- May need to implement QoS techniques 


• 0 • # • 0 
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Implement Quality of Service 

It may be necessary to implement QoS techniques, such as: 

• Protocol prioritization 

• Traffic shaping (for Frame Relay) 

• DiffServ 

• Maximum Transmit Unit (MTU) 

The customer’s existing WAN hardware may not support these options. It is 
important to know the capabilities of the existing WAN hardware. See the 
section titled “Hardware,” later in this lesson, for additional information. 

Serialization Delay 

Remember, serialization delay can occur when a small packet has to wait for a 
large packet to be sent over the link. This can result in end-to-end delay 
(latency) and variable delay (jitter). 

In a WAN environment where link speeds are low compared to the LAN, link 
speeds under 1 Mbps are subject to serialization delay. 

See the “Traffic Convergence Issues” lesson for a review of this topic. 
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Hardware 

The customer’s existing LAN and WAN hardware may not support the 
technologies available to implement QoS in the VoIP network. It is important 
to know the capabilities of the existing LAN and WAN hardware. 

It may be necessary to upgrade, replace, or expand the customer’s existing 
LAN and WAN hardware to meet the performance, redundancy, or QoS 
functionality requirements of the underlying data infrastructure for the support 
of VoIP. 

When you analyze network devices, especially WAN edge routers, remember 
that an upgrade of interfaces or link speeds does not always ensure that 
performance requirements will be met. Although a network router or switch 
can physically support a T1 or 100 Mb interface, the device may not be able to 
achieve full throughput on these interfaces. CPU utilizations, device 
architectures, and a ctivation of traffic filters or access lists can significantly 
impa ct performance. 

Redundancy 

You must also consider redundancy at various levels, such as: 

• Interfaces for critical connections, 

• Single points of failure in network devices at critical points within the 
network 

• Power 

• Whether the combination of the network design and devices provides for 
redundant or alternate paths in the event of a major link or device failure 

Dynamic Host Configuration Server 

If a customer plans to deploy soft IP clients, a Dynamic Host Configuration 
Server (DHCP) might be necessary to deploy soft IP clients on the company’s 
laptops. 
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Quality of Service 

A converged network mixes different types of traffic, each with very different 
requirements. These traffic types often react unfavorably when mixed. For 
example, a voice application expects no packet loss, and a minimal, fixed 
amount of packet delay. It operates in a steady fashion, with voice packets 
transmitted at fixed time intervals. This level of performance is obtained on a 
circuit-switched network. 

A best-effort IP network has varying amounts of packet loss, and variable 
delay usually caused by network congestion, which are the opposite of what is 
needed by a voice application. This can result in speech distortion, delay, and 
packet loss. 

Some important QoS parameters to analyze include: network availability, 
bandwidth, delay, and loss. As discussed earlier in this lesson in the section 
titled “Hardware,” knowledge of actual device support is essential. See the 
“Packet Design’ and “Traffic Convergence Issues” lessons, covered earlier in 
this course, for detailed information about QoS options and VoIP traffic 
requirements for network performance. 

Network Availability 

Network availability has the most significant effect on QoS. If the network is 
unavailable, even for brief periods of time, the user or application can achieve 
unpredictable or undesirable performance levels. Network availability is 
dependent on the availability of a redundant network. A redundant network 
generally includes the following elements: 

• Redundant devices such as interfaces, processor cards, and power supplies 

• Resilient networking protocols 

• Multiple physical connections, such as copper or fiber 

• Backup power sources 
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Bandwidth 

Bandwidth is a significant parameter that affects QoS. There are two types of 
bandwidth: Available Bandwidth and Guaranteed Bandwidth. 

Figure 4: Bandwidth 


• Available Bandwidth 

- All users compete for available bandwidth 

• Guaranteed Bandwidth 

-Guarantees minimum bandwidth and burst bandwidth 



Available Bandwidth 

With available bandwidth, the service purchased is typically available, but not 
guaranteed. For example, a customer purchase 256 Kbps. During light network 
traffic times, a user can achieve 256 Kbps, but under heavy network traffic 
conditions, the bandwidth is not achieved consistently. Many network 
operators oversubscribe the bandwidth on their network to maximize the return 
on their network infrastructure or leased bandwidth. This still does not ensure 
consistent bandwidth, as all users compete for available bandwidth. 

Guaranteed Bandwidth 

Some providers offer a Guaranteed Bandwidth service that guarantees a 
minimum bandwidth and burst bandwidth (duration of excess bandwidth use). 
With Guaranteed Bandwidth, subscribers get preferential treatment (QoS 
bandwidth guarantee) over the Available Bandwidth subscribers. 
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Voice Compression 

Another consideration with bandwidth is voice compression. The amount of 
bandwidth used by a VoIP call depends on if the voice signal is compressed 
and what link layer protocol the VoIP packet uses for transport. 

Is is recommended to compress the voice signals when using VoIP over a low 
bandwidth connection. There are several possible choices for voice 
compression. The G.729 CODEC provides the best balance of bandwidth and 
acceptable voice quality. G.729 compresses the voice call from 64 Kbps down 
to 8 Kbps. 

Figure 1: Voice Compression 


• Amount of bandwidth depends on compression and 
link layer protocol 

• G.711: 64 Kbps - approximately 

• G.729: 8 Kbps - approximately 


G.729 CODEC provides lowest bandwidth 
and near toll voice quality 


Note: Bandwidth requirements are estimates. 
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Quality of Service Versus Bandwidth 

One theory says that QoS is unnecessary. This theory contends that increasing 
bandwidth provides enough QoS for all applications. This theory also states 
that implementing QoS is complicated; adding bandwidth is easy. However, it 
is necessary to look at the QoS problem to determine if adding bandwidth will 
solve the problem. 

If all networks had so much bandwidth available that network congestion 
never occurred, QoS technology would not be needed. Some carrier network 
sections have huge amounts of bandwidth that have been carefully engineered 
to minimize congestion. Some carriers offer low latency connections across 
their Metropolitan Area Networks (MANs), cross-country networks, and 
continental long-haul networks. 

But high bandwidth connections are not available throughout the entire 
network. This is especially true for access networks, where the usual amount of 
bandwidth available is only several hundred Kbps. Traffic must be treated 
consistently to achieve a prescribed QoS level. Bandwidth differences in a 
network become potential congestion points. This can create poor quality and 
unpredictable QoS, even though the long-haul network offers excellent QoS 
performance. 
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Packet Loss and End-to-End Delay (Latency) 

Ui \ L U ° SS Can OCCur due to errors created by the physical medium used to transmit 

t ‘ le data - ^ oss a * so occur s when congested network nodes drop packets. 

C 1 £ End-to-end delay (latency) is the total time elapsed from speaking into a 

transmitter at one end to hearing the reconstructed sound on a receiver at the 
other end. Delay has a significant impact on the quality of a voice call. Most 
listeners can detect delay greater than 100 milliseconds (ms). At the 150 ms 
level, the delay becomes annoying. 

Variable Delay (Jitter) 

Jitter (also known as delay variation) has a pronounced effect on real-time, 
delay-sensitive applications, such as video and voice. These applications need 
to receive packets at a fairly constant rate, with a fixed delay between 
consecutive packets. If the arrival rate varies, the jitter affects the application’s 
performance. Minimal jitter is sometimes acceptable, but if jitter increases, the 
application can become unusable. 
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Protocols 

When assessing the network for VoIP readiness, observe the distribution of 
protocols in the network; specifically, on the WAN. Network Management 
Systems can poll network devices and analyze the results. 

Mixing Protocols 

Even with Maximum Transmission Unit (MTU) implemented, if there are 
protocols in use other than IP, those protocols can maintain larger frame sizes. 
This can introduce additional delay to the VoIP traffic. 

It is important to be aware that certain applications running over IP can set the 
frames with the “may fragment” bit set to 1, which prevents fragmentation. As 
part of the overall assessment process, the network analysis on the LAN will 
determine if there are any applications that have this bit setting. 

Time-Sensitive Protocols 


Some data protocols such as Structured Query Language (SQL), Internet 
Message Access Protocol (IMAP), and Simple Mail Transfer Protocol 
(SMTP), use primarily unicast traffic. Unicast traffic is traffic that goes to only 
one machine. This can effect your voice traffic by filling the pipe. Prioritizing 
the voice traffic should help eliminate this issue. Other chatty protocols such as 
NetBios Enhanced User Interface (NetBUI) spend much of their time 
broadcasting information to the network. Broadcasting is a way of sending 
traffic to all the machines on the network. When a host sees a broadcast 
message it must take time to read the message. This can interfere with the time 
sensitive VoIP traffic. Just placing the voice traffic in a higher queue does not 
avoid this problem since it is actually causing the host (IP terminal or client) to 
take the time to read the incoming broadcast traffic. If there is a lot of 
broadcast traffic on the network it is necessary to separate the voice traffic 
from the data traffic by placing them in separate VLANs. This means the 
devices on the voice VLAN will not see the traffic from the data VLAN. 
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Packet Loss Concealment 

Some network protocols, such as TCP/IP, retransmit dropped traffic. This is a 
problem for voice calls. Voice calls can not make use of the retransmitted 
packets because of the delay. When there are gaps in the voice signal due to 
network packet loss, the quality of the VoIP call will become choppy. In 
addition, if the traffic was originally dropped because of network congestion, 
the retransmission causes the congestion to spiral. This is why speech is not 
sent over a protocol with built in retransmission. It is sent over UDP/IP, which 
does not retransmit dropped packets. 

Packet Loss Concealment (PLC) generates a synthetic replacement signal 
based on the last signal received. The algorithm changes as more packets are 
lost. 

The G.729 and G.723.1 CODECs have built-in PLC and their quality drops 
slowly with increasing amounts of packet loss. G.711 and G.726 have no 
component PLC algorithm, but an external one can be added when these 
CODECs are used in a packet environment. A T1 standard has been adopted 
defining the PLC to be used with G.711.5 There is no comparable standard for 
G.726. 

Note: When good packets are restored, G.711 recovers immediately, whereas 
G.726 (ADPCM) and CELP based CODECs require a short time to re-adapt. 


Notes 
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Security 

A good network design considers security. Firewalls and intrusion detection 
systems protect the enterprise network from outside intrusions. Network 
address translation (NAT) devices can keep computer addresses hidden from 
hackers. However, be careful where you place the NAT devices, because it is 
difficult, if not impossible, to make VoIP work across a NAT. 

The following security features must be considered: 

• Encapsulation of VoIP packets 

• Firewall or Network Address Translation (NAT) that natively support 
H.323 or Session Initiation Protocol (SIP) 

• H.323- or SIP-enabled proxy server, used in conjunction with a firewall 

Routers might use NAT and IPSec for remote network users who connect to the 
network through the public internet using IPSec encryption. A firewall 
connection can be in place, as well. 

The network designer must consider the security policy in force, and see if the 
ports required for VoIP can go through the firewall. 
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Power and Wiring 

Inspect the power and wiring. Additional power or wiring may be necessary to 
support VoIP devices. For example: 

• Power over LAN (sometimes called inline power) for IP terminals 

• Redundant power supplies for the network equipment 

• Uninterruptible Power Supply (UPS) 

• Sufficient cooling in wiring closets for the UPS 

Note: If you have redundant power supplies, plug each power supply into a 
separate UPS. If possible, have each UPS on its own circuit so that if one 
circuit goes down you still have power from the other circuit. 
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Routing Protocols 

WAN Protocols 

Routing protocols in the WAN can be very important when considering how 
VoIP calls will be routed and how quickly fail-over occurs. When planning a 
VoIP network, be aware of what situations trigger a routing table update with 
respect to the routing protocol. This helps when predicting what path a VoIP 
flow might take during a failure in the network. 

Convergence 

Convergence is the point where all internetworking devices have a common 
understanding of the routing topology. The time it takes a network to re¬ 
converge after a link failure must be considered. The process can take several 
minutes, depending on the network size and routing protocol in use. 

LAN Protocols 

Routing protocols in the LAN must also be considered when implementing 
VoIP. 
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Traffic Flow 


It is important to assess traffic flows over a period of time (a week or longer) 
depending on the complexity of the network. Observe the peak times of day, 
week, and month to determine where the highest utilization exists. 
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From a voice perspective, an understanding of the circuit-switched facilities is 
important. Some important voice considerations include: 

• Flow 

• Calling patterns 

• Number of users 

• Peak values for time of day, day of week, or month 

Note: Call Detail Records (CDR) are a helpful resource when analyzing the 
voice traffic. 
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Notes 



Voice Quality 

You must also consider a method to ensure that the network consistently 
provides the same level of quality as the PSTN. Earlier in this course, you 
learned about some methods to measure voice quality: 

• MOS (Mean Opinion Score) 

• E-Model (ITU G. 107) 

The tables on the next page provide additional information about user 
satisfaction levels, as well as the impact of CODEC on voice quality. 

V Tip: It is recommended to use the E-Model, rather than the MOS (Mean 
Opinion Score), to calculate voice quality. The MOS is not as accurate 
when applied to VoIP networks, as it assumes the network is circuit- 
switched. 


flat* 


Network Assessment 


Issue 2.0 January 6, 2003 






Assess Network Resources 

Once you complete the pre-assessment, you are ready to perform the actual 
network assessment. An effective network assessment includes the following: 

• Simulate VoIP traffic flow 

• Assess link utilization 

• Observe routing protocols 

• Calculate voice quality 

• Identify jitter, one-way delay, and packet loss 

• Generate detailed reports 

The data and reports generated during the network assessment will help you 
make recommendations on any modifications that may be required to insure a 
successful VoIP deployment. 

Network Assessment Tools 

A variety of software tools are available to help you perform a network 
assessment. Some these include: 

• Sniffer Pro or Portable (Sniffer Technologies) 

• NetlQ Chariot (NetlQ Corporation) 

• NetlQ Qcheck (NetlQ Corporation) 

• NetlQ VoIP Assessor (NetlQ Corporation) 

• NetAlly (Viola Networks) 

• Multi-Router Traffic Grapher (Swiss Federal Institution) 


Notes 
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Sniffer Portable 

Sniffer Portable (also known as Sniffer Pro) is best-suited for identifying the 
existing protocols in a customer’s network to understand if potential problems 
may arise between applications and QoS recommendations. 

This software tool displays network activities on the monitoring PC in colorful 
graphs and charts. For example: 

• Bandwidth utilization 

• Packets per second 

• Broadcasts and multicasts 

• Protocol analysis 

Built-in expert network analysis helps you quickly identify faults and 
troubleshoot outages quickly. 

Using the product’s reporting tool, you can export data into popular third-party 
applications to create customized reports. 

The figure on the next page is an example of a Sniffer Portable screen. 
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Figure 3: Real-Time Network Analysis 
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NetlQ Chariot 

NetlQ Chariot (Chariot) emulates transaction traffic from real applications, 
tests and troubleshoots any segment of the network, and generates 
comprehensive reports. 

Chariot supports a variety of tests that enable you to measure network 
performance and stress. For example, Chariot’s maximum jitter measurement 
is most significant for identifying QoS impairments, such as latency and jitter. 

Performance Endpoints, or lightweight software agents, are installed on 
computers throughout the network. The endpoints emulate network traffic, 
including traffic with multiple data types, variable data rates, and multiple 
protocols. The endpoints collect information for analysis and reporting and 
generate reports that measure end-to-end performance and response time. 

Chariot also measures maximum jitter, delay, and lost data for streaming 
applications. 

The figure on the next page is an example of a Chariot screen. 
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Figure 4: Chariot VoIP Test Module 
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NetlQ Qcheck 

NetlQ Qcheck, by NetlQ Corporation, is a free software tool that measures 
network performance, such as: 

• Response time: Minimum, maximum, and average number of seconds it 
took to complete a transaction 

• Throughput: Amount of data per second that was successfully sent 
between the two endpoints 

• Streaming: Rate at which the streaming data was received by the second 
endpoint and the amount of packet loss that occurred 

• Traceroute: Number of hops, average hop latency, and the address and 
names of the host at each hop 

NetlQ Qcheck consists of a console with a graphical user interface and 
Performance Endpoints. The console sends instructions to the endpoints, 
which execute the test and return the results. 

A summary of the test results displays on the console. In addition, you can 
access more comprehensive information by pressing the Details button. The 
formatted test results display in a standard Web browser. 

The figure on the next page is an example of a NetlQ Qcheck screen. 
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NetlQ VoIP Assessor 

NetlQ VoIP Assessor (VoIP Assessor) is based on the technology of NetlQ 
Chariot. VoIP Assessor enables you to predict how well VoIP will work on the 
network prior to deployment. 

VoIP Assessor simulates VoIP traffic and produces reports that help you 
identify areas of concern, including jitter. 

A VoIP Assessor session includes these phases: 

• Define end-point computers and VoIP connectors that represent the 
network 

• Specify length of the assessment and the duration and frequency of calls 

• Check the availability of the defined endpoints and test connections 

• Start the assessment and monitor the results 

• Generate reports of the results 



Tip: Because you specify the duration of the session , intervention of an 
onsite engineer is not required. 


The figure on the next page is an example of a NetlQ VoIP Assessor screen. 
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Figure 5: VoIP Assessor Main Menu 
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Design the assessment 

•1 Create endpoint computers and oonnectors to represent the network you are 
® assessing. 

As an optional step, define additional parameters for running an assessment 
from behind a firewall or making calls through specific ports. Or customize 
data ranges used when reporting results. These parameters are accessible from 
the Options menu. 


ft Scheduling the Assessment 


Schedule the assessment. 

y Specify the length of the assessment and the duration and frequency of calls to 
be made. 


ft Verifying the Assessment Configuration 


s-c? Verify the assessment configuration. 

3 Check the availability of endpoints defined in the assessment and test the con¬ 
nections between them, plus any options defined. 


ft Running the Assessment 


Run the assessment. 

Start the assessment and monitor its progress. The VoIP Assessor application 
may be closed and re-opened while an assessment is running. Results are 
automatically saved to the database as die assessment proceeds. 


ft Reporting Assessment Results 


s ’-®p Report the Results. 

5 Generate a report describing the results of the assessment. Reports are opened 
as Microsoft Word documents (.doc). 
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NetAlly 

NetAlly (Viola Network) emulates network traffic (as deployed or as planned), 
analyzes the results, and generates reports at scheduled times or on demand. 
The primary measurements used in the analysis are delay, loss, jitter, and 
throughput. 

NetAlly consists of a Test Center, which is installed as a management process 
on a supported server, and Traffic Agents, which are software components that 
are installed on existing servers or computers at strategic locations within the 
network. This enables you to rapidly isolate the sources of network 
performance issues, from the server to the end-user desktop. NetAlly also 
provides the flexibility to verify the test results by repeating identical tests, as 
needed. 

The figure on the next page is an example of a NetAlly Assessor screen. 
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Multi Router Traffic Grapher 

The Multi Router Traffic Grapher (MRTG) is an SNMP tool that monitors the 
traffic load on network links in real time and displays the results on an HTML 
page. 

As a pre-deployment tool, MRTG can determine router and link utilization in a 
WAN environment. MRTG can collect statistics on any device that has an 
SNMP agent, and gathers statistics for the day, week, month, and year, without 
the necessity of an onsite engineer. 

In addition to monitoring traffic, you can use MRTG to monitor any SNMP 
variable you choose; for example: system load, login sessions, and modem 
availability. 

The figure on the next page is an example of an MRTG screen. 
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Network Improvements 

Once the network assessment is complete, use the information collected during 
the pre-assessment and actual assessment phases to determine 
recommendations. 

These recommendations may include: 

• Replace or upgrade existing hardware: 

Replace shared-media Ethernet hubs with Layer 2 switching at a 
minimum 

Utilize G.711 for LAN-based applications and G.729 for calls 
traversing the WAN. CODEC selection is based on overall objectives 
and cost targets for the VoIP deployment. 

On links below 1.5 Mb, do not exceed 50 percent total peak loading 

Make sure that delay does not exceed 150 ms. Packet loss should be 
less than 0.5 percent. 

• Implement QoS: 

Protocol prioritization 

Traffic shaping (for Frame Relay) 

Diffserve 
IP fragmentation 
Platform-queuing mechanisms 

• Negotiate new network service contracts and service level agreements: 

Availability 
- Call setup 
Performance 
Call Quality 
Incident Tracking 
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Practice 



Read each scenario. Describe the potential implementation issue the 
configuration presents and recommend the network improvement to insure a 
successful VoIP deployment. 


1. The customer uses shared media access to connect to the WAN. 


Issue: 


Recommendation: 

\ji/\ ki 
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3. The customer’s service level agreement with its PSTN provider does not 
ensure any level of prioritization once the call enters the WAN. 

Issue: 


Recommendation: 

yO 


PS T J 
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4. The data network includes firewalls and Network Address Translation 
(NAT) devices to protect the network from unauthorized access. 

Issue: 
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5. The home office has a larger bandwidth connection than the remote sites. 
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6. A company wants to equip its regional sales personnel with soft IP clients. 
Most of the personnel use laptop computers. 

Issue: 


Recommendation: 
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Answers to Practice 

If you successfully completed the Practice and are confident with your 
understanding of the material, then you have satisfied the lesson requirements. 
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Summary 

In this lesson, you learned that planning is vital to successfully deploy a Voice 
over IP (VoIP) solution in an existing network. You learned about the 
recommended VoIP network assessment process and areas and the tools 
available to assist you with network assessment process. You also learned how 
to develop customer recommendations for network improvements, based on 
sample network assessment scenarios in preparation for VoIP deployment. 
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OSI Reference Model 

Introduction 

To standardize concepts and facilitate understanding between data 
communication architectures, the International Standards Organization (ISO) 
developed the Open Systems Interconnection model, otherwise known as OSI. 
This reference model defines language and boundaries for establishing 
protocols so devices are “open” to one another, allowing communication 
between different networks. 

In communications, tasks are performed in a certain order. For example, a 
message cannot be sent before it is created. Therefore, a series of steps 
necessary to complete a process exist. These steps are known as layers. Each 
layer is dependent on the action of the previous layer. 

The OSI model defines seven layers. Each layer supports specific functions in 
computer communication. Each layer receives services from an adjacent layer, 
performs its own specific task, and transfers its output to a neighboring layer. 
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The Seven OSI Layers 

The seven OSI Layers are described in the following table. 


Model 

Layer 

Description 

7 

Application 

Acts as interface between applications and application server 
elements and supports the transfer of information from applications 
to the lower layers 

6 

Presentation 

Serves as the data translator for the network and functions as a pass¬ 
through protocol of information from adjacent layers 

5 

Session 

Provides connection services, such as the establishment and 
maintenance of a session 

4 

Transport 

Delivers messages; provides port and traffic management 

3 

Network 

Determines the physical path data will travel, based on network 
conditions and the destination of the message; provides forwarding 
and route discovery 

2 

Data Link 

Transfers traffic over physical link; provides flow control and error 
detection, depending upon the link type 

Includes two sub-layers: Media Access Control (MAC) and Logical 
Link Control (LLC) 

1 

Physical 

Defines the media and physical characteristics of the signals (for 
example, voltages); defines clocking, synchronization, and physical 
connectors 
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Interaction between the VoIP Protocol Suite and the OSI Model 

The figure below shows the relationship between the VoIP Protocol suite and 
the OSI model. 

Figure 1: Interaction between the Voice over Internet Protocol Suite and the OSI Model 


OSI Model 


Internet Protocol Suite 




Data or Other 
Support 

Voice 

RTP 

H.323, SIP 


Voice 

TCP or UDP 

UDP 

TCP or UDP 

Other 

Support 



Ethernet, ATM, PPP, Frame Relay, and Wireless protocols 


T1, El, SONET, Layer 1 Ethernet 


Layer 7 Application 
Layer 6 Presentation 


Layer 5 Session 


Layer 4 Transport 


Layer 3 Network 


Layer 2 Data link 


Layerl Physical 



Issue 2.0 January 6, 2003 


OSI Reference Model 























Page 6 of 28 






Page 7 of 28 


3 


Network Readiness Questionaire 


Wide Area Network (WAN) 


Please attach a logical diagram. 


Please attach a physical diagram. 


What types of links are in use on the WAN? 


What is the current utilization of those links? 


What are the peak delays on the WAN links? 


What link speeds are in use on the WAN? 


What WAN platforms are currently installed? 


Do the installed platforms support some form of QoS? 


What protocols are in use? 


What routing protocols are in use? 


What is the current flow of data and voice traffic? 


Is a Call Detail Record available? 
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Wide Area Network (WAN) 

What is the expected voice quality? 


What MOS score and (or) R Value is expected? 


What is the expected traffic distribution? 

Percentage of 

Voice: 

Percentage of Data: 

What transport method will be used? 


What is the maximum number of hops expected? 


What is the Router Forwarding Speed - Queueing Delay 
Distribution? 


What is the expected packet loss distribution? 
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Local Area Network (LAN) 


.... '• - <"!■ 


Please attach a logical diagram. 


Please attach a physical diagra. 


What link speeds are in use on the LAN? 


What is the current utilization of those links? 


What are the peak delays on the LAN links? 


What types of links are in use? 10/100/1000 



What LAN platforms are currently installed? 


Do the installed platforms support some form of QoS? 


What protocols are in use? 


What routing protocols are in use ? 


What is the current flow of data and voice traffic? 



Percentage of Voice: Percentage of Data: 


Is a Call Detail Record available? 
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Local Area Network (LAN) 


• '• ’ ' ' ' 

■ »>, ;> r 


What MOS score and (or) R Value is expected? 



What is the expected traffic distribution? 


What transport method will be used? 


Percentage of Voice: Percentage of Data: 


What is the maximum number of hops expected? 


Router Forwarding Speed - Queueing Delay Distribution 


What is the expected packet loss distribution? 
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Quality of Service (QoS) 


Please describe your proposed QoS strategy for the network. Include as much detail 
Please Attach. 

as possible. 
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Notes 
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Glossary 


This section defines the terms used in this lesson. It is important to have a basic 
understanding of these terms before you begin the course. 

Asynchronous Transfer Mode (ATM) 

ATM is a set of standard telecommunication interfaces defined by Tl, the 
ATM Forum, and International Telecommunications Union (ITU). A 
switched, connection-oriented, fixed-length cell-based transmission 
method specifically designed to run at high data rates and to carry a 
complete range of user traffic, including voice, data, and video signals over 
long and short distances. ATM uses dedicated media connections running 
in parallel, allowing simultaneous multiple connections through a single 
switch device at very high speeds. This service relies upon very small 
fixed-length packets (cells) to achieve speeds in the gigabit-per-second 
range. See also International Telecommunications Union (ITU). 

Available Bit Rate (ABR) 

An ATM (Asynchronous Transfer Mode) service category that guarantees a 
minimum amount of bandwidth, though it can be limited to a specified 
peak emission rate. It is not intended to support real-time applications. See 
also best-effort service. 

back-off error 

Ethernet NMM (Network Management Module) error indicating that a 
station attempting to transmit did not wait long enough following a 
collision before attempting to retransmit. Could be caused by a faulty NIC 
(Network Interface Controller) card. 

bandwidth 

A measure of the data-carrying capacity of a network connection or device. 
Analog is typically measured in cycles per second (Hertz), while digital is 
measured in bits per second (bps). 

best-effort service 

Quality of Service (QoS) class that has no specified parameters or 
assurances that the traffic will be delivered across the network to the target 
device. See also Available Bit Rate (ABR) and Unspecified Bit Rate 
(UBR). 

bits and bytes 

These two terms refer to the memory in a computer. A bit is the smallest 
quantity a computer can measure or detect. A bit corresponds to a binary 
digit (either 0 or 1). A byte is made up of eight bits, and is the primary 
measure for computer memory and disk storage. A byte is to a bit what a 
word is to a character. A byte is typically one character of information, 
such as a number, a punctuation mark, a letter, or a symbol. 
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bottleneck 

A system capacity constraint that may reduce traffic during peak load 
conditions. 

burst 

Traffic characterized by short periods of high intensity separated by fairly 
long intervals of little or no utilization. 

Busy Hour Traffic (BHT) 

Hour of the day with the heaviest phone traffic. This data is used to 
provision the number of trunks needed to handle ACD call traffic and the 
number of agents required to handle the traffic and to produce call center 
reports. 

Call Detail Recording (CDR) 

A feature that provides information on calls placed and received. CDR can 
be used by management to control the cost of telephone communications 
by charging back to clients and eliminating misuse by distributing costs by 
cost centers or departments. 

capacity 

The information-carrying ability of a telecommunications facility, group, 
network, or system measured in bits per second (bps). 

circuit-switching 

A communications model in which a dedicated communication path is 
established between two hosts and on which all packets travel, open only 
for the duration of the transmission. Once the connection is closed, other 
devices can use it. The telephone system is an example of a circuit- 
switched network. 

CODEC 

A chip located on a line card or in a telephone set that performs the analog 
to digital and digital to analog conversion of voice. 

collision 

The result of two stations trying to send packets at the same time, which 
causes fragments or garbled data (mutual destruction of the colliding 
packets). 

Committed Information Rate (CIR) 

In a Frame Relay network, each PVC (Permanent Virtual Circuit) is 
assigned a CIR that is measured in bits per second. The CIR represents the 
average capacity that the port connection allocates to the PVC. 

delay 

The wait time between two events. See also latency. 
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Domain Name Service (DNS) 

(1) Addressing system that incorporates the domain name into the IP 
address. As used on the Internet, some of the domains are: .gov (U.S. 
government), .edu (educational institution), and .com (commercial 
organization). 

(2) A server that can translate a symbolic name, for example, translate 
“Frank” into an IP address, such as 192.53.139.200. 

duplex 

Switched Ethernet connections can operate in either half- or full-duplex 
transmission modes. Full duplex mode doubles the speed of a device, for 
example, boosting lOBase-T switch operation to 20 Mbps and 100Base-T 
operation to 200 Mbps. 

Dynamic Host Configuration Protocol (DHCP) 

Ethernet protocol widely used in heterogeneous networks (such as those 
supporting Windows NT and other multiple protocols) that provides a 
centralized administration point for managing multiple operating systems. 
DHCP provides both static and dynamic address allocation. 

E-Model (ITU G.107) 

A computational model for use in transmission planning that is based on a 
narrow bandwidth sample (300 to 3400 Hz). The result of the E-Model 
calculation is called the R-Value (also known as the R-Factor or R). See 
also R-Value. 

Ethernet 

A LAN transport protocol developed by Xerox Corporation in cooperation 
with Digital Equipment Company and Intel in the late 1970s. Ethernet is a 
network protocol standard that specifies how data is placed on and 
retrieved from a common transmission medium. lOBase-T is the standard 
with a transfer rate of 10 Mbps. 

firewall 

A combination of hardware and software that limits the exposure of a 
computer or group of computers to an attack from outside. The primary 
purpose of an Internet firewall is to provide a single point of entry where a 
defense can be implemented, allowing access to resources on the Internet 
from within the organization, and providing controlled access from the 
Internet to hosts inside the organization's internal networks. 

Frame Relay (FR) 

A high-speed, packet switching WAN protocol, designed to provide 
efficient, high-speed frame or packet transmission with minimum delay. 
Frame relay uses minimal error detection and relies on higher-level 
protocols for error control. 
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hub 

A physical layer device, connected to other devices, that restores a signal's 
amplitude and timing for transfer across a network. Hubs provide Ethernet, 
token ring, and/or FDDI (Fiber Distributed Data Interface) functions; 
accept host, internetworking, and network management modules; and 
provide retiming/repeater, bridging, and network management 
functionality. A typical hub has multiple user ports to which computers and 
peripheral devices are attached. 

intelligent hub (also known as LAN switch) 

A manageable hub, meaning that each port on the hub can be configured, 
monitored, and enabled or disabled by a network operator from a hub 
management console. Hub management can also include processing 
functions and information gathering of network parameters, such as the 
number or types of transmitted packets, the number of errors, or the 
number of collisions. See also manageable hub, active hub, and passive 
hub. 

International Telecommunications Union (ITU) 

United Nations organization that develops and standardizes worldwide 
telecommunications. 

jitter 

Short-term instabilities in network signal timing, 
latency 

The time difference between sending a packet and receiving a response 
back. See also delay. 

layer 

A logically distinct level in network architecture. Communication 
networks are organized as a set of more or less independent protocols, each 
in a different layer; the lowest layer governs direct host-to-host 
communication between hardware at different hosts and the highest layer 
consists of user applications. Each layer builds on the layer beneath it using 
protocols appropriate to the layer. TCP/IP has five layers of protocols; OSI 
has seven. The methods of passing information from one layer to another 
are specified as part of the protocol suite, and changes within a protocol 
layer do not affect the other layers. 

link 

An electrical or fiber optic connection between a network station and a 
concentrator or between two concentrators. 
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Local Area Network (LAN) 

A communications network serving users within a limited geographical 
area, such as one floor of a building, controlled by a Network Operating 
System and using a transport protocol. User devices attached to a LAN 
include workstations, servers, and printers. Most LANs employ the 
Ethernet, token ring, or FDDI (Fiber Distributed Data Interface) access 
methods, or some combination of these. Several LANs can be 
interconnected to extend connectivity. 

logical network 

A network diagram created independent of physical device location that 
can include groups spread out over different locations (such as floors or 
even separate buildings). 

Maximum Transit Unit (MTU) 

The largest possible unit of data that can be transmitted on a given physical 
medium using a given protocol. 

Mean Opinion Score (MOS) 

Mean Opinion Score. A value that reflects the customer opinion of voice 
quality. It ranges from 0 to 5, where “0” means poor voice quality and “5” 
means excellent voice quality. 

Network Address Translation (NAT) 

A protocol that ensures network addresses are intelligible to the system. 
Network Management System (NMS) 

A system that provides network management across enterprise data 
networks. 

packet 

A group of bits, including data and control signals, arranged in a specific 
format and transmitted as a whole over a packet-switching network. The 
structure of a packet depends on the protocol. In general, a packet includes 
three principal elements: control information (destination, origin, length of 
packet), data to be transmitted, and error detection and correction bits. An 
information block identified by a label at layer 3 of the OSI reference 
model. 

packet switching 

A term used to describe protocols that divide messages into packets before 
they are sent. Each packet is then transmitted individually to its destination. 
Once all the packets forming a message arrive at the destination, they are 
recompiled into the original message. Most WAN protocols are based on 
packet-switching technologies. See also circuit switching. 
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Standards and Organizations 

www.ietf.org 

www.itu.org 


Signaling Protocols 

H.323 

www.iec.org/online/tutorials/h323/index.html 

www.admiral-group.com/netmeeting/videoconferencing/h323.htm 

www.openh323.org 

www.protocols.com/voip/typical_h323_call.htm 

www.packetizer.com/iptel/h323/papers/primer/ 

www.imtc.org/h323body.htm 

www.protocols.com/pbook/h323.htm 


SIP 

www.cconvergence.com/article/CTM20000608S0019 
www.faqs.org/rfcs/rfc2974.html 
www.landfield.com/rfcs/rfc2327.html 
www.cs.columbia.edu/~hgs/sip/papers.html 
www.radvision.com/papers/Cl_What_is_SIP.html 
spsc.inw.tugraz.at/courses/asp/ssOl/sip/S IP_descr.htm 
www.ietf.org/rfc/rfc2543.txt7numbe r=2543 
www.cs.columbia.edu/~hgs/papers/Wedl 19908_Mobility.pdf 
www.argreenhouse.com/SIP-mobile/Reference/html 

H323 versus SIP 

www.iptel.org/info/trends/sip.html 
www.tmcnet.com/it/0801 /0801 radv.htm 

www.globecom.net/ietf/draft/draft-agrawal-sip-h323-interworking-00.html 
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MGCP 

www.cconvergence.com/article/CTM20000608S0019 
www.faqs.org/rfcs/rfc2705.html 

www.networkmagazine.com/article/NMG20001OO4SO013 

MEGACO 

www.ietf.cnr.reston.va.us/html.charters/megaco-charter.html 
www.networkmagazine.com/article/NMG2001004S0013 
www.voicom.co.uk/About_MEGACO.htm 
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VoIP Bandwidth Demand Calculator 

Matthew F. Michels 
Sr. Consulting Engineer 
IP Telephony Solutions 
Nortel Networks 

Summary and Features: 

The Voice over IP (VoIP) Bandwidth Demand Calculator is designed to show a 
Network Designer the impact of VoIP on various segments of the converged 
voice/data IP network. The user can enter values for a) the number of 
concurrent VoIP calls traversing the network between two points, and b) the 
predicted bandwidth savings effect of enabling VAD (Voice Activity 
Detection, otherwise referred to as Silence Suppression. The user can also 
enter different values for Protocol Overhead based upon specific feature 
implementations of a given network. 

CODECs supported: 

• G.711 

• G.729 

• G.723 

Packetization Intervals supported: 

• 10 ms 

• 20 ms 

• 30 ms 

• 40 ms 

• 60 ms 

LAN/WAN technologies supported: 

• 802.3 LAN, 10 mbps, half-duplex 

• 802.3 LAN, 100 mbps, half- and full-duplex 

• PPP over Private Leased Line of various common speeds 

• Frame Relay over Access Lines of various speeds 

• ATM (AAL5) over Access Lines of various speeds 
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The tool provides a variety of results: 

• A “summary” page showing net bandwidth demand for each LAN/WAN 
technology for specified number of concurrent voice calls and VAD Effect, 
formatted for printing. Summary page shows Protocol Overhead settings 
used to create the calculations. 

• A “charts” page showing comparisons of "per call bandwidth demand" for 
each transport type versus packetization rate for G.711 and G.729 on two 
output charts/print pages. Charts page shows Protocol Overhead settings 
used to create the calculations. 

• A “Tables” page which lists the Protocol Overhead values used in the 
calculations. 

Two detailed calculations pages for each CODEC - one without VAD, and one 
with VAD (for example, G.711 and G.711 vad). Each detailed page shows 
Bandwidth Demand per call. Total Bandwidth Demand for number of trunks 
specified on the "summary" sheet, Percent Utilization level for various LAN 
speeds, and WAN Private Line or FR/ATM Access Line speeds. A Warning is 
indicated if bandwidth demand exceeds 70% utilization, and an error is 
indicated if bandwidth demand exceeds 100% utilization. 

Tool Usage: 

The Network Designer can control several input values - unlocked cells shaded 
in yellow background. The tool recalculates instantly whenever a value is 
changed. These are: 

• Number of Voice Trunks (on Summary sheet). This is the number of 
concurrent, active voice calls. 

• VAD Effect (Bandwidth Savings) (on Summary sheet). This is a 
percentage bandwidth reduction value (40% is suggested) 

• IP RTP Header Compression Overhead (on Tables sheet). Normal value is 
4 octets, but some implementations allow 2octets. 

• 802.3 Overhead (on Tables sheet). Value of 38 includes 802.3 header, 
preamble, and interframe gap. Other values could be 26 or 18. 

• Frame Relay Overhead (on Tables sheet). Normal value is 6 octets, but can 
be 5, 6, 7, 8, or more, depending upon “Flag Optimization” and use of 
Extended Addressing capabilities. 

• PPP Overhead (on Tables sheet). Normal value is 7 for a 2-octet FCS, or 9 
if a 4-octet FCS is used. 
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Fixed and Calculated fields on the Table sheet: 

• IP Overhead is set to 40 octets - 20 for IP, 8 for UDP, and 12 for RTP 
headers. 

• ATM Overhead is calculated using AAL5 rules, and is variable due to 
forcing traffic to fit fixed ATM 53-octet cell size. Various amounts of 
padding are used to fit the cell size, but will consume bandwidth that 
cannot be used by other applications. 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


4 : Number of Voice Trunks _ 

0% : VAD effect (Bandwidth savings) 


Protocol 

Overhead 

IP 

40 

IP (w/ he) 

5 

802.3 

18 

FR 

6 

PPP 

8 

ATM 

varies 


20 IP + 8 UDP + 12 RTP 

"RTP Header Compression” - often 4, can be 2 

Ethernet Hdr only 

Usually 6 or 5, can be more w/ Extended Addressing use 
Usually 7, can be 9 w/ 4-octet FCS 
Varies due to forcing fit to 53 octet Cells 


Full/Half Link Speed 


I 


10 ms Packetization, VAD off 


Bandwidth Bandwidth Bandwidth 


demand 


demand 


demand 


li 


10 ms Packetization, VAD on 


Bandwidth Bandwidth Bandwidth 


demand 


demand 


demand 


T yP e 

Link Type 

Duplex 

(kbps) 

1 (bps) 1 

(bps) 

(bps) 

(bps) 

(bps) 

(bps) 

Digital 

TDM 

Full 

n/a 

256,000 

32,000 

25,200 

256,000 

32,000 

25,200 

VoIP 

802.3 

Half 

10,000 

883,200 

435,200 

n/a 

883,200 

435,200 

n/a 

VoIP 

802.3 

Half 

100,000 

883,200 

435,200 

n/a 

883,200 

435,200 

n/a 

VoIP 

802.3 

Full 

100,000 

441,600 

217,600 

n/a 

441,600 

217,600 

n/a 

VoIP 

Frame Relay 

Full 

any 

403,200 

179,200 

n/a 

403,200 

179,200 

n/a 

VoIP 

PPP 

Full 

any 

409,600 

185,600 

n/a 

409,600 

185,600 

n/a 

VoIP 

ATM (AAL-5) 

Full 

any 

508,800 

339,200 

n/a 

508,800 

339,200 

n/a 

VolP/hc 

Frame Relay 

Full 

any 

291,200 

67,200 

n/a 

291,200 

67,200 

n/a 

VolP/hc 

PPP 

Full 

any 

297,600 

73,600 

n/a 

297,600 

73,600 

n/a 

VoFR 

Frame Relay 

Full 

any 

284,800 

60,800 

n/a 

284,800 

60,800 

n/a 

VoATM 

ATM (AAL-5) 

Full 

any 

339,200 

169,600 

n/a 

339,200 

169,600 

n/a 


Full/Half Link Speed 


I 


20 ms Packetization, VAD off 


20 ms Packetization, VAD on 


Bandwidth Bandwidth 
demand demand 


G.723 


Bandwidth 

demand 


Bandwidth Bandwidth 
demand demand 


G.723 


Bandwidth 

demand 



Link Type 

Duplex 

(kbps) 

1 (bps) | 

(bps) 

(bps) 

(bps) 

(bps) 

(bps) 

Digital 

TDM 

Full 

n/a 

256,000 

32,000 

25,200 

256,000 

32,000 

25,200 

VoIP 

802.3 

Half 

10,000 

697,600 

249,600 

n/a 

697,600 

249,600 

n/a 

VoIP 

802.3 

Half 

100,000 

697,600 

249,600 

n/a 

697,600 

249,600 

n/a 

VoIP 

802.3 

Full 

100,000 

348,800 

124,800 

n/a 

348,800 

124,800 

n/a 

VoIP 

Frame Relay 

Full 

any 

329,600 

105,600 

n/a 

329,600 

105,600 

n/a 

VoIP 

PPP 

Full 

any 

332,800 

108,800 

n/a 

332,800 

108,800 

n/a 

VoIP 

ATM (AAL-5) 

Full 

any 

424,000 

169,600 

n/a 

424,000 

169,600 

n/a 

VolP/hc 

Frame Relay 

Full 

any 

273,600 

49,600 

n/a 

273,600 

49,600 

n/a 

VolP/hc 

PPP 

Full 

any 

276,800 

52,800 

n/a 

276,800 

52,800 

n/a 

VoFR 

Frame Relay 

Full 

any 

270,400 

46,400 

n/a 

270,400 

46,400 

n/a 

VoATM 

ATM (AAL-5) 

Full 

any 

339,200 

84,800 

n/a 

339,200 

84,800 

n/a 
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Voice over IP (VoIP) Bandwidth Demand Calculator 



_ 30 ms Packetization, VAD off __ 30 ms Packetization, VAD on 

G.711 G.729 G.723 ~ G.711 G.729 G.723 

Bandwidth Bandwidth Bandwidth Bandwidth Bandwidth Bandwidth 

Voice over Full/Half Link Speed demand demand demand demand demand demand 


Type 

Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(bps) 

(bps) 

(bps) 

(bps) 

Digital 

TDM 

Full 

n/a 

256,000 

32,000 

25,200 

256,000 

32,000 

25,200 

VoIP 

802.3 

Half 

10,000 

635,733 

187,733 

174,933 

635,733 

187,733 

174,933 

VoIP 

802.3 

Half 

100,000 

635,733 

187,733 

174,933 

635,733 

187,733 

174,933 

VoIP 

802.3 

Full 

100,000 

317,867 

93,867 

87,467 

317,867 

93,867 

87,467 

VoIP 

Frame Relay 

Full 

any 

305,067 

81,067 

74,667 

305,067 

81,067 

74,667 

VoIP 

PPP 

Full 

any 

307,200 

83,200 

76,800 

307,200 

83,200 

76,800 

VoIP 

ATM (AAL-5) 

Full 

any 

339,200 

113,067 

113,067 

339,200 

113,067 

113,067 

VolP/hc 

Frame Relay 

Full 

any 

267,733 

43,733 

37,333 

267,733 

43,733 

37,333 

VolP/hc 

PPP 

Full 

any 

269,867 

45,867 

39,467 

269,867 

45,867 

39,467 

VoFR 

Frame Relay 

Full 

any 

265,600 

41,600 

35,200 

265,600 

41,600 

35,200 

VoATM 

ATM (AAL-5) 

Full 

any 

339,200 

56,533 

56,533 

339,200 

56,533 

56,533 


40 ms Packetization. VAD off _ 40 ms Packetization. VAD on 

G.711 G.729 G.723 ~ G.711 G.729 G.723 

Bandwidth Bandwidth Bandwidth Bandwidth Bandwidth Bandwidth 


Voice over Full/Half Link Speed demand demand demand demand demand demand 


EnSI 

Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(bps) 

(bps) 

(bps) 

(bps) 

Digital 

TDM 

Full 

n/a 

256,000 

32,000 

25,200 

256,000 

32,000 

25,200 

VoIP 

802.3 

Half 

10,000 

604,800 

156,800 

n/a 

604,800 

156,800 

n/a 

VoIP 

802.3 

Half 

100,000 

604,800 

156,800 

n/a 

604,800 

156,800 

n/a 

VoIP 

802.3 

Full 

100,000 

302,400 

78,400 

n/a 

302,400 

78,400 

n/a 

VoIP 

Frame Relay 

Full 

any 

292,800 

68,800 

n/a 

292,800 

68,800 

n/a 

VoIP 

PPP 

Full 

any 

294,400 

70,400 

n/a 

294,400 

70,400 

n/a 

VoIP 

ATM (AAL-5) 

Full 

any 

339,200 

84,800 

n/a 

339,200 

84,800 

n/a 

VolP/hc 

Frame Relay 

Full 

any 

264,800 

40.800 

n/a 

264.800 

40,800 

n/a 

VolP/hc 

PPP 

Full 

any 

266,400 

42,400 

n/a 

266,400 

42,400 

n/a 

VoFR 

Frame Relay 

Full 

any 

263,200 

39,200 

n/a 

263,200 

39,200 

n/a 

VoATM 

ATM (AAL-5) 

Full 

any 

296,800 

42,400 

n/a 

296,800 

42,400 

n/a 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


4 

: Number of Voice Trunks 

0% 

: VAD effect (Bandwidth savings) 


Protocol 

Overhead 

IP 

40 

IP (w/ he) 

5 

802.3 

18 

FR 

6 

PPP 

8 

ATM 

varies 


(from Line 4 of "Tables") 

20 IP + 8 UDP + 12 RTP 

"RTP Header Compression" - often 4, can be 2 

Ethernet Hdr only 

Usually 6 or 5, can be more w/ Extended Addressing use 
Usually 7, can be 9 w/ 4-octet FCS 
Varies due to forcing fit to 53 octet Cells 


Voice 

Type 


over 

Link Type 


Full/Half 

Duplex 


Link Speed 
(kbps) 


60 ms Packetization, VAD off 


G.711 


Bandwidth 

demand 

(bps) 


G.729 


Bandwidth 

demand 

(bps) 


G.723 


Bandwidth 

demand 

(bps) 


60 ms Packetization, VAD on 


G.711 


Bandwidth 

demand 

(bps) 


G.729 


Bandwidth 

demand 

(bps) 


G.723 


Bandwidth 

demand 

(bps) 


Digital 

TDM 

Full 

n/a 

256,000 

32,000 

25,200 

256,000 

32,000 

25,200 

VoIP 

802.3 

Half 

10,000 

573,867 

125,867 

113,067 

573,867 

125,867 

113,067 

VoIP 

802.3 

Half 

100,000 

573,867 

125,867 

113,067 

573,867 

125,867 

113,067 

VoIP 

802.3 

Full 

100,000 

286,933 

62,933 

56,533 

286,933 

62,933 

56,533 

VoIP 

Frame Relay 

Full 

any 

280,533 

56,533 

50,133 

280,533 

56,533 

50,133 

VoIP 

PPP 

Full 

any 

281,600 

57,600 

51,200 

281,600 

57,600 

51,200 

VoIP 

ATM (AAL-5) 

Full 

any 

310,933 

84,800 

56,533 

310,933 

84,800 

56,533 

VolP/hc 

Frame Relay 

Full 

any 

261,867 

37,867 

31,467 

261,867 

37,867 

31,467 

VolP/hc 

PPP 

Full 

any 

262,933 

38,933 

32,533 

262,933 

38,933 

32,533 

VoFR 

Frame Relay 

Full 

any 

260,800 

36,800 

30,400 

260,800 

36,800 

30,400 

VoATM 

ATM (AAL-5) 

Full 

any 

310,933 

56,533 

56,533 

310,933 

56,533 

56,533 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Overhead (Octets - a.k.a. Bytes) 


Codec 

Packetization 

(ms) 

Pkts/sec 

Codec 
Rate (bps) 

Voice 

Payload 

Size IP 

(Bytes) (IP/UTP/RTP) 

IP 

(RTP Hdr 
Comp) 

802.3 

Frame Relay 
(2 octet header, 

8 w/ 4 oct hdr) 

PPP 

(7 = default, 
can be 9) 

ATM 

(IP/AAL- 

G.711 

10 

100.00 

64000 

80 40 

5 

18 

6 

8 

39 

G.711 

20 

50.00 

64000 

160 40 

5 

18 

6 

8 

65 

G.711 

30 

33.33 

64000 

240 40 

5 

18 

6 

8 

38 

G.711 

40 

25.00 

64000 

320 40 

5 

18 

6 

8 

64 

G.711 

60 

16.67 

64000 

480 40 

5 

18 

6 

8 

63 

G.729 A/B 

10 

100.00 

8000 

10 40 

5 

18 

6 

8 

56 

G.729 A/B 

20 

50.00 

8000 

20 40 

5 

18 

6 

8 

46 

G.729 A/B 

30 

33.33 

8000 

30 40 

5 

18 

6 

8 

36 

G.729 A/B 

40 

25.00 

8000 

40 40 

5 

18 

6 

8 

26 

G.729 A/B 

60 

16.67 

8000 

60 40 

5 

18 

6 

8 

59 

G.723 

30 

33.33 

6400 

24 40 

5 

18 

6 

8 

42 

G.723 

60 

16.67 

6400 

48 40 

5 

18 

6 

8 

18 



1000/ #ms 

_per_pkt 

IP Headers 


18 - 802.3 info header and tailer (w/o preamble) 






IP = 20 octets 

AAA 

26 += 802.3 Preamble adds an extra 8 octets of overhead 





UDP = 8 octets 

AAA 

38 += 802.3 InterFrame Gap adds an extra 12 octets of overhead 





RTP = 12 octets 

AAA 


AAA 

AAA 

AAA 


can be 2 octets 
usually 4 octets 


AAA AAA Overhead varies due to ft 

AAA 7 w/ default 2-oct FCS 
AAA 9 w/opt. 4-oct FCS 

5 w/ default 2-oct header, and start flag of next frame = end fl: 

6 w/ default 2-oct hdr, start flag and end flag on each frame 

7 w/ 3-oct hdr (extended addressing) 

8 w/ 4-oct hdr (extended addressing) 
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bits per second 


VoIP Per Call Bandwidth Demand for G.711 


300,000 

250,000 

200,000 

150,000 

100,000 

50,000 



■ 802.3 (HD) 

□ 802.3 (FD) 

□ PPP 

■ FR 

□ ATM 


10 20 30 40 60 

Packetization Rate (ms) 


G.711 VoIP 1 

Pkt Ivl 

802.3 (HD) 

802.3 (FD) 

PPP 

FR 

ATM 

10 

220.800 

110.400 

102.400 

100.800 

127,200 

20 

174.400 

87,200 

83.200 

82.400 

106,000 

30 

158,933 

79,467 

76,800 

76.267 

84,800 

40 

151,200 

75,600 

73,600 

73.200 

84,800 

60 

143,467 

71.733 

70.400 

70,133 

77.733 


Protocol 

Overhead 

IP 

40 

IP (w/ he) 

5 

802.3 

18 

FR 

6 

PPP 

8 

ATM 

varies 
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VoIP Per Call Bandwidth Demand for G.729 

160,000 
140,000 
120,000 

S 100,000 

(/> 

80,000 
I 60,000 

40,000 

20,000 

10 20 30 40 60 

Packetization Rate (ms) 


|G 729 VoIP | 

Pkt Ivl 

802.3 (HD) 

802.3 (FD) 

PPP 

FR 

ATM 

10 

108.800 

54,400 

46.400 

44,800 

84,800 

20 

62,400 

31.200 

27.200 

26,400 

42,400 

30 

46.933 

23,467 

20.800 

20.267 

28.267 

40 

39.200 

19,600 

17.600 

17.200 

21.200 

60 

31,467 

15,733 

14.400 

14.133 

21,200 


Protocol 

Overhead 

IP 

40 

IP (w/ he) 

5 

802.3 

18 

FR 

6 

PPP 

8 

ATM 

varies 



■ 802.3 (HD) 

□ 802.3 (FD) 

□ PPP 

■ FR 

□ ATM 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.711 (no VAD) 


Demand exceeds 100%! (can't do it!) <-!! 
Demand exceeds 70% (caution) <-• 


G.711 w/ 10ms Packetization 






Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 

Link Type 

VoIP over Ethernet LAN 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

VoIP 

802.3 

Half 

10,000 

220,800 

883,200 

9% 

VoIP 

802.3 

Half 

100,000 

220,800 

883,200 

1% 

VoIP 802.3 

VoIP over Frame Relay w/o 1 

Full 100,000 

RTP Header Compression 

110,400 

441,600 

0% 

VoIP 

Frame Relay 

Full 

56 

100,800 

403,200 

720% <-!! 

VoIP 

Frame Relay 

Full 

64 

100,800 

403,200 

630% <-!! 

VoIP 

Frame Relay 

Full 

128 

100,800 

403,200 

315% <-!! 

VoIP 

Frame Relay 

Full 

256 

100,800 

403,200 

158% <-!! 

VoIP 

Frame Relay 

Full 

512 

100,800 

403,200 

79% <-* 

VoIP 

Frame Relay 

Full 

768 

100,800 

403,200 

53% 

VoIP 

Frame Relay 

Full 

1,024 

100,800 

403,200 

39% 

VoIP 

Frame Relay 

Full 

1,536 

100,800 

403,200 

26% 

VoIP 

Frame Relay 

Full 

3,072 

100,800 

403,200 

13% 

VoIP 

Frame Relay 

Full 

6,144 

100,800 

403,200 

7% 

VoIP 

Frame Relay 

Full 

9,216 

100,800 

403,200 

4% 

VoIP 

Frame Relay 

Full 

12,288 

100,800 

403,200 

3% 

VoIP 

Frame Relay 

Full 

15,360 

100,800 

403,200 

3% 

VoIP 

Frame Relay 

Full 

18,432 

100,800 

403,200 

2% 

VoIP Frame Relay 

VoIP over PPP link w/o RTP 

Full 43,008 

Header Compression 

100,800 

403,200 

1% 

VoIP 

PPP 

Full 

56 

102,400 

409,600 

731% <-!! 

VoIP 

PPP 

Full 

64 

102,400 

409,600 

640% <-!! 

VoIP 

PPP 

Full 

128 

102,400 

409,600 

320% <-!! 

VoIP 

PPP 

Full 

256 

102,400 

409,600 

160% <-!! 

VoIP 

PPP 

Full 

512 

102,400 

409,600 

80% <-* 

VoIP 

PPP 

Full 

768 

102,400 

409,600 

53% 

VoIP 

PPP 

Full 

1,024 

102,400 

409,600 

40% 

VoIP PPP 

VoIP in ATM/AAL-5 

Full 

1,536 

102,400 

409,600 

27% 

VoIP 

ATM (AAL-5) 

Full 

1,536 

127,200 

508,800 

33% 

VoIP 

ATM (AAL-5) 

Full 

3,072 

127,200 

508,800 

17% 

VoIP 

ATM (AAL-5) 

Full 

6,144 

127,200 

508,800 

8% 

VoIP 

ATM (AAL-5) 

Full 

9,216 

127,200 

508,800 

6% 

VoIP 

ATM (AAL-5) 

Full 

12,288 

127,200 

508,800 

4% 

VoIP 

ATM (AAL-5) 

Full 

15,360 

127,200 

508,800 

3% 

VoIP 

ATM (AAL-5) 

Full 

18,432 

127,200 

508,800 

3% 

VoIP 

ATM (AAL-5) 

Full 

43,008 

127,200 

508,800 

1% 

VoIP 

ATM (AAL-5) 

Full 

50,112 

127,200 

508,800 

1% 

VoIP 

ATM (AAL-5) 

Full 

150,336 

127,200 

508,800 

0% 

VoIP 

ATM (AAL-5) 

Full 

601,344 

127,200 

508,800 

0% 

VoIP 

ATM (AAL-5) 

Full 

2,405,376 

127,200 

508,800 

0% 

VoIP 

ATM (AAL-5) 

Full 

4,810,752 

127,200 

508,800 

0% 

VoIP ATM (AAL-5) Full 9,621,504 

VoIP over Frame Relay w/ RTP Header Compression 

127,200 

508,800 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.711 (no VAD) Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* 

G.711 w/ 10ms Packetization 






Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

VoIP 

Frame Relay 

Full 

56 

72,800 

291,200 

520% <-!! 

VoIP 

Frame Relay 

Full 

64 

72,800 

291,200 

455% <-!! 

VoIP 

Frame Relay 

Full 

128 

72,800 

291,200 

228% <-!! 

VoIP 

Frame Relay 

Full 

256 

72,800 

291,200 

114% <-!! 

VoIP 

Frame Relay 

Full 

512 

72,800 

291,200 

57% 

VoIP 

Frame Relay 

Full 

768 

72,800 

291,200 

38% 

VoIP 

Frame Relay 

Full 

1,024 

72,800 

291,200 

28% 

VoIP 

Frame Relay 

Full 

1,536 

72,800 

291,200 

19% 

VoIP 

Frame Relay 

Full 

3,072 

72,800 

291,200 

9% 

VoIP 

Frame Relay 

Full 

6,144 

72,800 

291,200 

5% 

VoIP 

Frame Relay 

Full 

9,216 

72,800 

291,200 

3% 

VoIP 

Frame Relay 

Full 

12,288 

72,800 

291,200 

2% 

VoIP 

Frame Relay 

Full 

15,360 

72,800 

291,200 

2% 

VoIP 

Frame Relay 

Full 

18,432 

72,800 

291,200 

2% 

VoIP 

Frame Relay 

Full 

43,008 

72,800 

291,200 

1% 

VoIP over PPP link w/ RTP Header Compression 




VoIP 

PPP 

Full 

56 

74,400 

297,600 

531% <-!! 

VoIP 

PPP 

Full 

64 

74,400 

297,600 

465% <-!! 

VoIP 

PPP 

Full 

128 

74,400 

297,600 

233% <-!! 

VoIP 

PPP 

Full 

256 

74,400 

297,600 

116% <-!! 

VoIP 

PPP 

Full 

512 

74,400 

297,600 

58% 

VoIP 

PPP 

Full 

768 

74,400 

297,600 

39% 

VoIP 

PPP 

Full 

1,024 

74,400 

297,600 

29% 

VoIP 

PPP 

Full 

1,536 

74,400 

297,600 

19% 

Voice directly in Frame Relay 






VoFR 

Frame Relay 

Full 

56 

71,200 

284,800 

509% <-!! 

VoFR 

Frame Relay 

Full 

64 

71,200 

284,800 

445% <-!! 

VoFR 

Frame Relay 

Full 

128 

71,200 

284,800 

223% <-!! 

VoFR 

Frame Relay 

Full 

256 

71,200 

284,800 

111% <-!! 

VoFR 

Frame Relay 

Full 

512 

71,200 

284,800 

56% 

VoFR 

Frame Relay 

Full 

768 

71,200 

284,800 

37% 

VoFR 

Frame Relay 

Full 

1,024 

71,200 

284,800 

28% 

VoFR 

Frame Relay 

Full 

1,536 

71,200 

284,800 

19% 

VoFR 

Frame Relay 

Full 

3,072 

71,200 

284,800 

9% 

VoFR 

Frame Relay 

Full 

6,144 

71,200 

284,800 

5% 

VoFR 

Frame Relay 

Full 

9,216 

71,200 

284,800 

3% 

VoFR 

Frame Relay 

Full 

12,288 

71,200 

284,800 

2% 

VoFR 

Frame Relay 

Full 

15,360 

71,200 

284,800 

2% 

VoFR 

Frame Relay 

Full 

18,432 

71,200 

284,800 

2% 

VoFR 

Frame Relay 

Full 

43,008 

71,200 

284,800 

1% 

Voice directly in ATM/AAL-5 






VoATM 

ATM (AAL-5) 

Full 

1,536 

84,800 

339,200 

22% 

VoATM 

ATM (AAL-5) 

Full 

3,072 

84,800 

339,200 

11% 

VoATM 

ATM (AAL-5) 

Full 

6,144 

84,800 

339,200 

6% 

VoATM 

ATM (AAL-5) 

Full 

9,216 

84,800 

339,200 

4% 

VoATM 

ATM (AAL-5) 

Full 

12,288 

84,800 

339,200 

3% 

VoATM 

ATM (AAL-5) 

Full 

15,360 

84,800 

339,200 

2% 

VoATM 

ATM (AAL-5) 

Full 

18,432 

84,800 

339,200 

2% 

VoATM 

ATM (AAL-5) 

Full 

43,008 

84,800 

339,200 

1% 

VoATM 

ATM (AAL-5) 

Full 

50,112 

84,800 

339,200 

1% 

VoATM 

ATM (AAL-5) 

Full 

150,336 

84,800 

339,200 

0% 

VoATM 

ATM (AAL-5) 

Full 

601,344 

84,800 

339,200 

0% 

VoATM 

ATM (AAL-5) 

Full 

2,405,376 

84,800 

339,200 

0% 

VoATM 

ATM (AAL-5) 

Full 

4,810,752 

84,800 

339,200 

0% 

VoATM 

ATM (AAL-5) 

Full 

9,621,504 

84,800 

339,200 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 



J 

) 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-• Demand exceeds 70% (caution) <-* 


G.711 w/ 20ms Packetization 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

174,400 

697,600 

7% 

174,400 

697,600 

1% 

87,200 

348,800 

0% 

82,400 

329,600 

589% <-!! 

82,400 

329,600 

515% <-!! 

82,400 

329,600 

258% <-!! 

82,400 

329,600 

129% <-!! 

82,400 

329,600 

64% 

82,400 

329,600 

43% 

82,400 

329,600 

32% 

82,400 

329,600 

21% 

82,400 

329,600 

11% 

82,400 

329,600 

5% 

82,400 

329,600 

4% 

82,400 

329,600 

3% 

82,400 

329,600 

2% 

82,400 

329,600 

2% 

82,400 

329,600 

1% 

83,200 

332,800 

594% <-!! 

83,200 

332,800 

520% <-!! 

83,200 

332,800 

260% <-!! 

83,200 

332,800 

130% <-!! 

83,200 

332,800 

65% 

83,200 

332,800 

43% 

83,200 

332,800 

33% 

83,200 

332,800 

22% 

106,000 

424,000 

28% 

106,000 

424,000 

14% 

106,000 

424,000 

7% 

106,000 

424,000 

5% 

106,000 

424,000 

3% 

106,000 

424,000 

3% 

106,000 

424,000 

2% 

106,000 

424,000 

1% 

106,000 

424,000 

1% 

106,000 

424,000 

0% 

106,000 

424,000 

0% 

106,000 

424,000 

0% 

106,000 

424,000 

0% 

106,000 

424,000 

0% 


G.711 w/ 30ms Packetization 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

158,933 

635,733 

6% 

158,933 

635,733 

1% 

79,467 

317,867 

0% 

76,267 

305,067 

545% <-!! 

76,267 

305,067 

477% <-!! 

76,267 

305,067 

238% <-!! 

76,267 

305,067 

119% <-!! 

76,267 

305,067 

60% 

76,267 

305,067 

40% 

76,267 

305,067 

30% 

76,267 

305,067 

20% 

76,267 

305,067 

10% 

76,267 

305,067 

5% 

76,267 

305,067 

3% 

76,267 

305,067 

2% 

76,267 

305,067 

2% 

76,267 

305,067 

2% 

76,267 

305,067 

1% 

76,800 

307,200 

549% <-!! 

76,800 

307,200 

480% <-!! 

76,800 

307,200 

240% <-!! 

76,800 

307,200 

120% <-!! 

76,800 

307,200 

60% 

76,800 

307,200 

40% 

76,800 

307,200 

30% 

76,800 

307,200 

20% 

84,800 

339,200 

22% 

84,800 

339,200 

11% 

84,800 

339,200 

6% 

84,800 

339,200 

4% 

84,800 

339,200 

3% 

84,800 

339,200 

2% 

84,800 

339,200 

2% 

84,800 

339,200 

1% 

84,800 

339,200 

1% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 


P 

P 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-• Demand exceeds 70% (caution) <-’ 


G.711 w/ 20ms Packetization G.711 w/ 30ms Packetization 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

68,400 

273,600 

489% <-!! 

66,933 

267,733 

478% <-!! 

68,400 

273,600 

428% <-!! 

66,933 

267.733 

418% <-!! 

68,400 

273,600 

214% <-!! 

66,933 

267,733 

209% <-!! 

68,400 

273,600 

107% <-!! 

66,933 

267,733 

105% <-!! 

68,400 

273,600 

53% 

66,933 

267,733 

52% 

68,400 

273,600 

36% 

66,933 

267,733 

35% 

68,400 

273,600 

27% 

66,933 

267,733 

26% 

68,400 

273,600 

18% 

66,933 

267,733 

17% 

68,400 

273,600 

9% 

66,933 

267,733 

9% 

68,400 

273,600 

4% 

66,933 

267,733 

4% 

68,400 

273,600 

3% 

66,933 

267,733 

3% 

68,400 

273,600 

2% 

66,933 

267,733 

2% 

68,400 

273,600 

2% 

66.933 

267,733 

2% 

68,400 

273,600 

1% 

66,933 

267,733 

1% 

68,400 

273,600 

1% 

66,933 

267,733 

1% 

69,200 

276,800 

494% <-!! 

67,467 

269,867 

482% <-!! 

69,200 

276,800 

433% <-!! 

67,467 

269,867 

422% <-!! 

69,200 

276,800 

216% <-!! 

67,467 

269,867 

211% <-!! 

69,200 

276,800 

108% <-!! 

67,467 

269,867 

105% <-!! 

69,200 

276,800 

54% 

67,467 

269,867 

53% 

69,200 

276,800 

36% 

67,467 

269,867 

35% 

69,200 

276,800 

27% 

67,467 

269,867 

26% 

69,200 

276,800 

18% 

67,467 

269,867 

18% 

67,600 

270,400 

483% <-!! 

66,400 

265,600 

474% <-!! 

67,600 

270,400 

423% <-!! 

66,400 

265,600 

415% <-!! 

67,600 

270,400 

211% <-!! 

66,400 

265,600 

208% <-!! 

67,600 

270,400 

106% <•!! 

66,400 

265,600 

104% <-!! 

67,600 

270,400 

53% 

66,400 

265,600 

52% 

67,600 

270,400 

35% 

66,400 

265,600 

35% 

67,600 

270,400 

26% 

66,400 

265,600 

26% 

67,600 

270,400 

18% 

66,400 

265,600 

17% 

67,600 

270,400 

9% 

66,400 

265,600 

9% 

67,600 

270,400 

4% 

66,400 

265,600 

4% 

67,600 

270,400 

3% 

66,400 

265,600 

3% 

67,600 

270,400 

2% 

66,400 

265,600 

2% 

67,600 

270,400 

2% 

66,400 

265,600 

2% 

67,600 

270,400 

1% 

66,400 

265,600 

1% 

67,600 

270,400 

1% 

66,400 

265,600 

1% 

84,800 

339,200 

22% 

84,800 

339,200 

22% 

84,800 

339,200 

•11% 

84,800 

339,200 

11% 

84,800 

339,200 

6% 

84,800 

339,200 

6% 

84,800 

339,200 

4% 

84,800 

339,200 

4% 

84,800 

339,200 

3% 

84,800 

339,200 

3% 

84,800 

339,200 

2% 

84,800 

339,200 

2% 

84,800 

339,200 

2% 

84,800 

339,200 

2% 

84,800 

339,200 

1% 

84,800 

339,200 

1% 

84,800 

339,200 

1% 

84,800 

339,200 

1% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 



Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) <-• 


G.711 w/ 40ms Packetization 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

151,200 

604,800 

6% 

151,200 

604,800 

1% 

75,600 

302,400 

0% 

73,200 

292,800 

523% <-!! 

73,200 

292,800 

458% <-!! 

73,200 

292,800 

229% <-!! 

73,200 

292,800 

114% <-!! 

73,200 

292,800 

57% 

73,200 

292,800 

38% 

73,200 

292,800 

29% 

73,200 

292,800 

19% 

73,200 

292,800 

10% 

73,200 

292,800 

5% 

73,200 

292,800 

3% 

73,200 

292,800 

2% 

73,200 

292,800 

2% 

73,200 

292,800 

2% 

73,200 

292,800 

1% 

73,600 

294,400 

526% <-!! 

73,600 

294,400 

460% <-!! 

73,600 

294,400 

230% <-!! 

73,600 

294,400 

115% <-!! 

73,600 

294,400 

58% 

73,600 

294,400 

38% 

73,600 

294,400 

29% 

73,600 

294,400 

19% 

84,800 

339,200 

22% 

84,800 

339,200 

11% 

84,800 

339,200 

6% 

84,800 

339,200 

4% 

84,800 

339,200 

3% 

84,800 

339,200 

2% 

84,800 

339,200 

2% 

84,800 

339,200 

1% 

84,800 

339,200 

1% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 

84,800 

339,200 

0% 


G.711 w/60ms Packetization 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

143,467 

573,867 

6% 

143,467 

573,867 

1% 

71,733 

286,933 

0% 

70,133 

280,533 

501% <-!! 

70,133 

280,533 

438% <-!! 

70,133 

280,533 

219% <-!! 

70,133 

280,533 

110% <-!! 

70,133 

280,533 

55% 

70,133 

280,533 

37% 

70,133 

280,533 

27% 

70,133 

280,533 

18% 

70,133 

280,533 

9% 

70,133 

280,533 

5% 

70,133 

280,533 

3% 

70,133 

280,533 

2% 

70,133 

280,533 

2% 

70,133 

280,533 

2% 

70,133 

280,533 

1% 

70,400 

281,600 

503% <-!! 

70,400 

281,600 

440% <-!! 

70,400 

281,600 

220% <-!! 

70,400 

281,600 

110% <-!! 

70,400 

281,600 

55% 

70,400 

281,600 

37% 

70,400 

281,600 

28% 

70,400 

281,600 

18% 

77,733 

310,933 

20% 

77,733 

310,933 

10% 

77,733 

310,933 

5% 

77,733 

310,933 

3% 

77,733 

310,933 

3% 

77,733 

310,933 

2% 

77,733 

310,933 

2% 

77,733 

310,933 

1% 

77,733 

310,933 

1% 

77,733 

310,933 

0% 

77,733 

310,933 

0% 

77,733 

310,933 

0% 

77,733 

310,933 

0% 

77,733 

310,933 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) <-” 


G.711 w/ 40ms Packetization G.711 w/ 60ms Packetization 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

66,200 

264,800 

473% <-!! 

65,467 

261,867 

468% <-!! 

66,200 

264,800 

414% <-!! 

65,467 

261,867 

409% <-!! 

66,200 

264,800 

207% <-!! 

65,467 

261,867 

205% <-!! 

66,200 

264,800 

103% <-!! 

65,467 

261,867 

102% <-!! 

66,200 

264,800 

52% 

65,467 

261,867 

51% 

66,200 

264,800 

34% 

65,467 

261,867 

34% 

66,200 

264,800 

26% 

65,467 

261,867 

26% 

66,200 

264,800 

17% 

65,467 

261,867 

17% 

66,200 

264,800 

9% 

65,467 

261,867 

9% 

66,200 

264,800 

4% 

65,467 

261,867 

4% 

66,200 

264,800 

3% 

65,467 

261,867 

3% 

66,200 

264,800 

2% 

65,467 

261,867 

2% 

66,200 

264,800 

2% 

65,467 

261,867 

2% 

66,200 

264,800 

1% 

65,467 

261,867 

1% 

66,200 

264,800 

1% 

65,467 

261,867 

1% 

66,600 

266,400 

476% <-!! 

65,733 

262,933 

470% <-!! 

66,600 

266,400 

416% <-!! 

65,733 

262,933 

411% <-!! 

66,600 

266,400 

208% <-!! 

65,733 

262,933 

205% <-!! 

66,600 

266,400 

104% <-!! 

65,733 

262,933 

103% <-!! 

66,600 

266,400 

52% 

65,733 

262,933 

51% 

66,600 

266,400 

35% 

65,733 

262,933 

34% 

66,600 

266,400 

26% 

65,733 

262,933 

26% 

66,600 

266,400 

17% 

65,733 

262,933 

17% 

65,800 

263,200 

470% <-!! 

65,200 

260,800 

466% <-!! 

65,800 

263,200 

411% <-!! 

65,200 

260,800 

408% <-!! 

65,800 

263,200 

206% <-!! 

65,200 

260,800 

204% <-!! 

65,800 

263,200 

103% <-!! 

65,200 

260,800 

102% <-!! 

65,800 

263,200 

51% 

65,200 

260,800 

51% 

65,800 

263,200 

34% 

65,200 

260,800 

34% 

65,800 

263,200 

26% 

65,200 

260,800 

25% 

65,800 

263,200 

17% 

65,200 

260,800 

17% 

65,800 

263,200 

9% 

65,200 

260,800 

8% 

65,800 

263,200 

4% 

65,200 

260,800 

4% 

65,800 

263,200 

3% 

65,200 

260,800 

3% 

65,800 

263,200 

2% 

65,200 

260,800 

2% 

65,800 

263,200 

2% 

65,200 

260,800 

2% 

65,800 

263,200 

1% 

65,200 

260,800 

1% 

65,800 

263,200 

1% 

65,200 

260,800 

1% 

74,200 

296,800 

19% 

77,733 

310,933 

20% 

74,200 

296,800 

10% 

77,733 

310,933 

10% 

74.200 

296,800 

5% 

77,733 

310,933 

5% 

74,200 

296,800 

3% 

77,733 

310,933 

3% 

74,200 

296,800 

2% 

77,733 

310,933 

3% 

74,200 

296,800 

2% 

77,733 

310,933 

2% 

74,200 

296,800 

2% 

77,733 

310,933 

2% 

74,200 

296,800 

1% 

77,733 

310,933 

1% 

74,200 

296,800 

1% 

77,733 

310,933 

1% 

74,200 

296,800 

0% 

77,733 

310,933 

0% 

74,200 

296,800 

0% 

77,733 

310,933 

0% 

74,200 

296,800 

0% 

77,733 

310,933 

0% 

74,200 

296,800 

0% 

77,733 

310,933 

0% 

74,200 

296,800 

0% 

77,733 

310,933 

0% 


By: Matthew F. Michels 


Ver. 2.1, 3/8/2001 


Page 12 of 75 



Voice over IP (VoIP) Bandwidth Demand Calculator 



G.729(noVAD) Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-• 






Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

VoIP over Ethernet LAN 






VoIP 

802.3 

Half 

10,000 

108,800 

435,200 

4% 

VoIP 

802.3 

Half 

100,000 

108,800 

435,200 

0% 

VoIP 

802.3 

Full 

100,000 

54,400 

217,600 

0% 

VoIP over Frame Relay w/o RTP Header Compression 




VoIP 

Frame Relay 

Full 

56 

44,800 

179,200 

320% <-!! 

VoIP 

Frame Relay 

Full 

64 

44,800 

179,200 

280% <-!! 

VoIP 

Frame Relay 

Full 

128 

44,800 

179,200 

140% <-!! 

VoIP 

Frame Relay 

Full 

256 

44,800 

179,200 

70% <-* 

VoIP 

Frame Relay 

Full 

512 

44,800 

179,200 

35% 

VoIP 

Frame Relay 

Full 

768 

44,800 

179,200 

23% 

VoIP 

Frame Relay 

Full 

1,024 

44,800 

179,200 

18% 

VoIP 

Frame Relay 

Full 

1,536 

44,800 

179,200 

12% 

VoIP 

Frame Relay 

Full 

3,072 

44,800 

179,200 

6% 

VoIP 

Frame Relay 

Full 

6,144 

44,800 

179,200 

3% 

VoIP 

Frame Relay 

Full 

9,216 

44,800 

179,200 

2% 

VoIP 

Frame Relay 

Full 

12,288 

44,800 

179,200 

1% 

VoIP 

Frame Relay 

Full 

15,360 

44,800 

179,200 

1% 

VoIP 

Frame Relay 

Full 

18,432 

44,800 

179,200 

1% 

VoIP 

Frame Relay 

Full 

43,008 

44,800 

179,200 

0% 

VoIP over PPP link w/o RTP Header Compression 




VoIP 

PPP 

Full 

56 

46,400 

185,600 

331% <-!! 

VoIP 

PPP 

Full 

64 

46,400 

185,600 

290% <-!! 

VoIP 

PPP 

Full 

128 

46,400 

185,600 

145% <-!! 

VoIP 

PPP 

Full 

256 

46,400 

185,600 

73% <-' 

VoIP 

PPP 

Full 

512 

46,400 

185,600 

36% 

VoIP 

PPP 

Full 

768 

46,400 

185,600 

24% 

VoIP 

PPP 

Full 

1,024 

46,400 

185,600 

18% 

VoIP 

PPP 

Full 

1,536 

46,400 

185,600 

12% 

VoIP in ATM/AAL-5 






VoIP 

ATM (AAL-5) 

Full 

1,536 

84,800 

339,200 

22% 

VoIP 

ATM (AAL-5) 

Full 

3,072 

84,800 

339,200 

11% 

VoIP 

ATM (AAL-5) 

Full 

6,144 

84,800 

339,200 

6% 

VoIP 

ATM (AAL-5) 

Full 

9,216 

84,800 

339,200 

4% 

VoIP 

ATM (AAL-5) 

Full 

12,288 

84,800 

339,200 

3% 

VoIP 

ATM (AAL-5) 

Full 

15,360 

84,800 

339,200 

2% 

VoIP 

ATM (AAL-5) 

Full 

18,432 

84,800 

339,200 

2% 

VoIP 

ATM (AAL-5) 

Full 

43,008 

84,800 

339,200 

1% 

VoIP 

ATM (AAL-5) 

Full 

50,112 

84,800 

339,200 

1% 

VoIP 

ATM (AAL-5) 

Full 

150,336 

84,800 

339,200 

0% 

VoIP 

ATM (AAL-5) 

Full 

601,344 

84,800 

339,200 

0% 

VoIP 

ATM (AAL-5) 

Full 

2,405,376 

84,800 

339,200 

0% 

VoIP 

ATM (AAL-5) 

Full 

4,810,752 

84,800 

339,200 

0% 

VoIP 

ATM (AAL-5) 

Full 

9,621,504 

84,800 

339,200 

0% 


P 

P 

: 


By: Matthew F. Michels 


Ver. 2.1, 3/8/2001 


Page 13 of 75 



Voice over IP (VoIP) Bandwidth Demand Calculator 


G.729 (no VAD) 


Demand exceeds 100%! (can't do it!) <-!! 
Demand exceeds 70% (caution) <-* 


G.729 w/ 10ms Packetization 






Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

VoIP over Frame Relay w/ RTP Header Compression 




VoIP 

Frame Relay 

Full 

56 

16,800 

67,200 

120% <-!! 

VoIP 

Frame Relay 

Full 

64 

16,800 

67,200 

105% <-!! 

VoIP 

Frame Relay 

Full 

128 

16,800 

67,200 

53% 

VoIP 

Frame Relay 

Full 

256 

16,800 

67,200 

26% 

VoIP 

Frame Relay 

Full 

512 

16,800 

67,200 

13% 

VoIP 

Frame Relay 

Full 

768 

16,800 

67,200 

9% 

VoIP 

Frame Relay 

Full 

1,024 

16,800 

67,200 

7% 

VoIP 

Frame Relay 

Full 

1,536 

16,800 

67,200 

4% 

VoIP 

Frame Relay 

Full 

3.072 

16,800 

67,200 

2% 

VoIP 

Frame Relay 

Full 

6,144 

16,800 

67,200 

1% 

VoIP 

Frame Relay 

Full 

9,216 

16,800 

67,200 

1% 

VoIP 

Frame Relay 

Full 

12,288 

16,800 

67,200 

1% 

VoIP 

Frame Relay 

Full 

15,360 

16,800 

67,200 

0% 

VoIP 

Frame Relay 

Full 

18,432 

16,800 

67,200 

0% 

VoIP 

Frame Relay 

Full 

43,008 

16,800 

67,200 

0% 

VoIP over PPP link w/ RTP Header Compression 




VoIP 

PPP 

Full 

56 

18,400 

73,600 

131% <-!! 

VoIP 

PPP 

Full 

64 

18,400 

73,600 

115% <-!! 

VoIP 

PPP 

Full 

128 

18,400 

73,600 

58% 

VoIP 

PPP 

Full 

256 

18,400 

73,600 

29% 

VoIP 

PPP 

Full 

512 

18,400 

73,600 

14% 

VoIP 

PPP 

Full 

768 

18,400 

73,600 

10% 

VoIP 

PPP 

Full 

1,024 

18,400 

73,600 

7% 

VoIP 

PPP 

Full 

1,536 

18,400 

73,600 

5% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.729 (no VAD) 


over Full/Half Link Speed 
Link Type Duplex (kbps) 

Voice directly in Frame Relay 


VoFR 

Frame Relay 

Full 

56 

VoFR 

Frame Relay 

Full 

64 

VoFR 

Frame Relay 

Full 

128 

VoFR 

Frame Relay 

Full 

256 

VoFR 

Frame Relay 

Full 

512 

VoFR 

Frame Relay 

Full 

768 

VoFR 

Frame Relay 

Full 

1,024 

VoFR 

Frame Relay 

Full 

1,536 

VoFR 

Frame Relay 

Full 

3,072 

VoFR 

Frame Relay 

Full 

6,144 

VoFR 

Frame Relay 

Full 

9,216 

VoFR 

Frame Relay 

Full 

12,288 

VoFR 

Frame Relay 

Full 

15,360 

VoFR 

Frame Relay 

Full 

18,432 

VoFR 

Frame Relay 

Full 

43,008 


Demand exceeds 100%! (can't do it!) <-!! 
Demand exceeds 70% (caution) <-* 

G.729 w/ 10ms Packetization 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

15,200 

60,800 

109% 

15,200 

60,800 

95% 

15,200 

60,800 

48% 

15,200 

60,800 

24% 

15,200 

60,800 

12% 

15,200 

60,800 

8% 

15,200 

60,800 

6% 

15,200 

60,800 

4% 

15,200 

60,800 

2% 

15,200 

60,800 

1% 

15,200 

60,800 

1% 

15,200 

60,800 

0% 

15,200 

60,800 

0% 

15,200 

60,800 

0% 

15,200 

60,800 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.729 (no VAD) 


Demand exceeds 100%! (can't do it!) <-!! 
Demand exceeds 70% (caution) <-* 


G.729 w/ 10ms Packetization 






Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

Voice directly in ATM/AAL-5 






VoATM 

ATM (AAL-5) 

Full 

1,536 

42,400 

169,600 

11% 

Vo ATM 

ATM (AAL-5) 

Full 

3,072 

42,400 

169,600 

6% 

VoATM 

ATM (AAL-5) 

Full 

6,144 

42,400 

169,600 

3% 

VoATM 

ATM (AAL-5) 

Full 

9,216 

42,400 

169,600 

2% 

VoATM 

ATM (AAL-5) 

Full 

12,288 

42,400 

169,600 

1% 

VoATM 

ATM (AAL-5) 

Full 

15,360 

42,400 

169,600 

1% 

VoATM 

ATM (AAL-5) 

Full 

18,432 

42,400 

169,600 

1% 

VoATM 

ATM (AAL-5) 

Full 

43,008 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

50,112 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

150,336 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

601,344 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

2,405,376 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

4,810,752 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

9,621,504 

42,400 

169,600 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 



Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-• Demand exceeds 70% (caution) <-' 


G.729 w/ 20ms Packetization 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

62,400 

249,600 

2% 

62,400 

249,600 

0% 

31,200 

124,800 

0% 

26,400 

105,600 

189% <-!! 

26,400 

105,600 

165% <-!! 

26,400 

105,600 

83% <-’ 

26,400 

105,600 

41% 

26,400 

105,600 

21% 

26,400 

105,600 

14% 

26,400 

105,600 

10% 

26,400 

105,600 

7% 

26,400 

105,600 

3% 

26,400 

105,600 

2% 

26,400 

105,600 

1% 

26,400 

105.600 

1% 

26,400 

105,600 

1% 

26,400 

105,600 

1% 

26,400 

105,600 

0% 

27,200 

108,800 

194% <-!! 

27,200 

108,800 

170% <-!! 

27,200 

108,800 

85% <-• 

27,200 

108,800 

43% 

27,200 

108,800 

21% 

27,200 

108,800 

14% 

27,200 

108,800 

11% 

27,200 

108,800 

7% 

42,400 

169,600 

11% 

42,400 

169,600 

6% 

42,400 

169,600 

3% 

42,400 

169,600 

2% 

42,400 

169,600 

1% 

42,400 

169,600 

1% 

42,400 

169,600 

1% 

42,400 

169,600 

0% 

42,400 

169,600 

0% 

42,400 

169,600 

0% 

42,400 

169,600 

0% 

42,400 

169,600 

0% 

42,400 

169,600 

0% 

42,400 

169,600 

0% 


G.729 w/ 30ms Packetization 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

46,933 

187,733 

2% 

46,933 

187,733 

0% 

23,467 

93,867 

0% 

20,267 

81,067 

145% 

20,267 

81,067 

127% 

20,267 

81,067 

63% 

20,267 

81,067 

32% 

20,267 

81,067 

16% 

20,267 

81,067 

11% 

20,267 

81,067 

8% 

20,267 

81,067 

5% 

20,267 

81,067 

3% 

20,267 

81,067 

1% 

20,267 

81,067 

1% 

20,267 

81,067 

1% 

20,267 

81,067 

1% 

20,267 

81,067 

0% 

20,267 

81,067 

0% 

20,800 

83,200 

149% 

20,800 

83,200 

130% 

20,800 

83,200 

65% 

20,800 

83,200 

33% 

20,800 

83,200 

16% 

20,800 

83,200 

11% 

20,800 

83,200 

8% 

20,800 

83,200 

5% 

28,267 

113,067 

7% 

28,267 

113,067 

4% 

28,267 

113,067 

2% 

28,267 

113,067 

1% 

28,267 

113,067 

1% 

28,267 

113,067 

1% 

28,267 

113,067 

1% 

28,267 

113,067 

0% 

28,267 

113,067 

0% 

28,267 

113,067 

0% 

28,267 

113,067 

0% 

28,267 

113,067 

0% 

28,267 

113,067 

0% 

28,267 

113,067 

0% 


P 

P 

P 

P 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) 
Demand exceeds 70% (caution) 

<-!! Demand exceeds 100%! (can't do it!) 

<-* Demand exceeds 70% (caution) 

G.729 w/ 20ms Packetization 

G.729 w/ 30ms Packetization 

Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

12,400 

49,600 

89% 

<-* 10,933 

43,733 

78% 

12,400 

49,600 

78% 

<-* 10,933 

43,733 

68% 

12,400 

49,600 

39% 

10,933 

43,733 

34% 

12,400 

49,600 

19% 

10,933 

43,733 

17% 

12,400 

49,600 

10% 

10,933 

43,733 

9% 

12,400 

49,600 

6% 

10,933 

43,733 

6% 

12,400 

49,600 

5% 

10,933 

43,733 

4% 

12,400 

49,600 

3% 

10,933 

43,733 

3% 

12,400 

49,600 

2% 

10,933 

43,733 

1% 

12,400 

49,600 

1% 

10,933 

43,733 

1% 

12,400 

49,600 

1% 

10,933 

43,733 

0% 

12,400 

49,600 

0% 

10,933 

43,733 

0% 

12,400 

49,600 

0% 

10,933 

43,733 

0% 

12,400 

49,600 

0% 

10,933 

43,733 

0% 

12,400 

49,600 

0% 

10,933 

43,733 

0% 

13,200 

52,800 

94% 

<-’ 11,467 

45,867 

82% 

13,200 

52,800 

83% 

<-' 11,467 

45,067 

72% 

13,200 

52,800 

41% 

11,467 

45,867 

36% 

13,200 

52,800 

21% 

11,467 

45,867 

18% 

13,200 

52,800 

10% 

11,467 

45,867 

9% 

13,200 

52,800 

7% 

11,467 

45,867 

6% 

13,200 

52,800 

5% 

11,467 

45,867 

4% 

13,200 

52,800 

3% 

11,467 

45,867 

3% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) <-’ 


G.729 w/ 20ms Packetization G.729 w/ 30ms Packetization 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

11,600 

46,400 

83% <-* 

10,400 

41,600 

74% 

11,600 

46,400 

73% <-* 

10,400 

41,600 

65% 

11,600 

46,400 

36% 

10,400 

41,600 

33% 

11,600 

46,400 

18% 

10,400 

41,600 

16% 

11,600 

46,400 

9% 

10,400 

41,600 

8% 

11,600 

46,400 

6% 

10,400 

41,600 

5% 

11,600 

46,400 

5% 

10,400 

41,600 

4% 

11,600 

46,400 

3% 

10,400 

41,600 

3% 

11,600 

46,400 

2% 

10,400 

41,600 

1% 

11,600 

46,400 

1% 

10,400 

41,600 

1% 

11,600 

46,400 

1% 

10,400 

41,600 

0% 

11,600 

46,400 

0% 

10,400 

41,600 

0% 

11,600 

46,400 

0% 

10,400 

41,600 

0% 

11,600 

46,400 

0% 

10,400 

41,600 

0% 

11,600 

46,400 

0% 

10,400 

41,600 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-’ Demand exceeds 70% (caution) <-’ 

G.729 w/20ms Packetization G.729 w/ 30ms Packetization 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

21,200 

84,800 

6% 

14,133 

56,533 

4% 

21,200 

84,800 

3% 

14,133 

56,533 

2% 

21,200 

84,800 

1% 

14,133 

56,533 

1% 

21,200 

84,800 

1% 

14,133 

56,533 

1% 

21,200 

84,800 

1% 

14,133 

56,533 

0% 

21,200 

84,800 

1% 

14,133 

56,533 

0% 

21,200 

84,800 

0% 

14,133 

56,533 

0% 

21,200 

84,800 

0% 

14,133 

56,533 

0% 

21,200 

84,800 

0% 

14,133 

56,533 

0% 

21,200 

84,800 

0% 

14,133 

56,533 

0% 

21,200 

84,800 

0% 

14,133 

56,533 

0% 

21,200 

84,800 

0% 

14,133 

56,533 

0% 

21,200 

84,800 

0% 

14,133 

56,533 

0% 

21,200 

84,800 

0% 

14,133 

56,533 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-• Demand exceeds 70% (caution) <-’ 

G.729 w/ 40ms Packetization G.729 w/ 60ms Packetization 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

39,200 

156,800 

2% 

31,467 

125,867 

1% 

39,200 

156,800 

0% 

31,467 

125,867 

0% 

19,600 

78,400 

0% 

15,733 

62,933 

0% 


17,200 

68,800 

123% <-!! 

14,133 

56,533 

101% <- 

17,200 

68,800 

108% <-!! 

14,133 

56,533 

88% <- 

17,200 

68,800 

54% 

14,133 

56,533 

44% 

17,200 

68,800 

27% 

14,133 

56,533 

22% 

17,200 

68,800 

13% 

14,133 

56,533 

11% 

17,200 

68,800 

9% 

14,133 

56,533 

7% 

17,200 

68,800 

7% 

14,133 

56,533 

6% 

17,200 

68,800 

4% 

14,133 

56,533 

4% 

17,200 

68,800 

2% 

14,133 

56,533 

2% 

17,200 

68,800 

1% 

14,133 

56,533 

1% 

17,200 

68,800 

1% 

14,133 

56,533 

1% 

17,200 

68,800 

1% 

14,133 

56,533 

0% 

17,200 

68,800 

0% 

14,133 

56,533 

0% 

17,200 

68,800 

0% 

14,133 

56,533 

0% 

17,200 

68,800 

0% 

14,133 

56,533 

0% 

17,600 

70,400 

126% <-!! 

14,400 

57,600 

103% <- 

17,600 

70,400 

110% <-!! 

14,400 

57,600 

90% <- 

17,600 

70,400 

55% 

14,400 

57,600 

45% 

17,600 

70,400 

28% 

14,400 

57,600 

23% 

17,600 

70,400 

14% 

14,400 

57,600 

11% 

17,600 

70,400 

9% 

14,400 

57,600 

8% 

17,600 

70,400 

7% 

14,400 

57,600 

6% 

17,600 

70,400 

5% 

14,400 

57,600 

4% 

21,200 

84,800 

6% 

21,200 

84,800 

6% 

21,200 

84,800 

3% 

21,200 

84,800 

3% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 ■ 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) <-* 


G.729 w/ 40ms Packetization G.729 w/ 60ms Packetization 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

10,200 

40,800 

73% <-' 

9,467 

37,867 

68% 

10,200 

40,800 

64% 

9,467 

37,867 

59% 

10,200 

40,800 

32% 

9,467 

37,867 

30% 

10,200 

40,800 

16% 

9,467 

37,867 

15% 

10,200 

40,800 

8% 

9,467 

37,867 

7% 

10,200 

40,800 

5% 

9,467 

37,867 

5% 

10,200 

40,800 

4% 

9,467 

37,867 

4% 

10,200 

40,800 

3% 

9,467 

37,867 

2% 

10,200 

40,800 

1% 

9,467 

37,867 

1% 

10,200 

40,800 

1% 

9,467 

37,867 

1% 

10,200 

40,800 

0% 

9,467 

37,867 

0% 

10,200 

40,800 

0% 

9,467 

37,867 

0% 

10,200 

40,800 

0% 

9,467 

37,867 

0% 

10,200 

40,800 

0% 

9,467 

37,867 

0% 

10,200 

40,800 

0% 

9,467 

37,867 

0% 

10,600 

42,400 

76% <-’ 

9,733 

38,933 

70% 

10,600 

42,400 

66% 

9,733 

38,933 

61% 

10,600 

42,400 

33% 

9,733 

38,933 

30% 

10,600 

42,400 

17% 

9,733 

38,933 

15% 

10,600 

42,400 

8% 

9,733 

38,933 

8% 

10,600 

42,400 

6% 

9,733 

38,933 

5% 

10,600 

42,400 

4% 

9,733 

38,933 

4% 

10,600 

42,400 

3% 

9,733 

38,933 

3% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


<-!! Demand exceeds 100%! (can't do it!) <-!! 
<-’ Demand exceeds 70% (caution) <-* 


Demand exceeds 100%! (can't do it!) 
Demand exceeds 70% (caution) 

G.729 w/ 40ms Packetization 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

9,800 

39,200 

70% <-' 

9,800 

39,200 

61% 

9,800 

39,200 

31% 

9,800 

39,200 

15% 

9,800 

39,200 

8% 

9,800 

39,200 

5% 

9,800 

39,200 

4% 

9,800 

39,200 

3% 

9,800 

39,200 

1% 

9,800 

39,200 

1% 

9,800 

39,200 

0% 

9,800 

39,200 

0% 

9,800 

39,200 

0% 

9,800 

39,200 

0% 

9,800 

39,200 

0% 


G.729 w/ 60ms Packetization 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

9,200 

36,800 

66% 

9,200 

36,800 

58% 

9,200 

36,800 

29% 

9,200 

36,800 

14% 

9,200 

36,800 

7% 

9,200 

36,800 

5% 

9,200 

36,800 

4% 

9,200 

36,800 

2% 

9,200 

36,800 

1% 

9,200 

36,800 

1% 

9,200 

36,800 

0% 

9,200 

36,800 

0% 

9,200 

36,800 

0% 

9,200 

36,800 

0% 

9,200 

36,800 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) <-* 

G.729 w/ 40ms Packetization G.729 w/ 60ms Packetization 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

10,600 

42,400 

3% 

14,133 

56,533 

4% 

10,600 

42,400 

1% 

14,133 

56,533 

2% 

10,600 

42,400 

1% 

14,133 

56,533 

1% 

10,600 

42,400 

0% 

14,133 

56,533 

1% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 
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• 










p 










p 










p 




Voice over IP (VoIP) Bandwidth Demand Calculator 



p 










p 

G.723 (no VAD) 





<-!! 



T 





G.723 is only available in increments <-* 

G.723 is only available in inert 

T 





of 30ms packetization 


of 30ms packetization 

k 





G.723 w/ 10ms Packetization 

G.723 w/ 20ms Packe 

f 





Bandwidth 

Total 

Link 

Bandwidth 

Total 

9 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

L 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

r 

VoIP over Ethernet LAN 








9 

VoIP 

802.3 

Half 

10.000 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

802.3 

Half 

100,000 

n/a 

n/a 

0% 

n/a 

n/a 

5 

VoIP 

802.3 

Full 

100,000 

n/a 

n/a 

0% 

n/a 

n/a 

• 

VoIP over Frame Relay w/o RTP Header Compression 






p 

\ 

VoIP 

Frame Relay 

Full 

56 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

64 

n/a 

n/a 

0% 

n/a 

n/a 

# 

VoIP 

Frame Relay 

Full 

128 

n/a 

n/a 

0% 

n/a 

n/a 

w 

VoIP 

Frame Relay 

Full 

256 

n/a 

n/a 

0% 

n/a 

n/a 

• 

VoIP 

Frame Relay 

Full 

512 

n/a 

n/a 

0% 

n/a 

n/a 

A 

VoIP 

Frame Relay 

Full 

768 

n/a 

n/a 

0% 

n/a 

n/a 

w 

VoIP 

Frame Relay 

Full 

1,024 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

Frame Relay 

Full 

1,536 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

Frame Relay 

Full 

3,072 

n/a 

n/a 

0% 

n/a 

n/a 

• 

VoIP 

Frame Relay 

Full 

6,144 

n/a 

n/a 

0% 

n/a 

n/a 

09 

VoIP 

Frame Relay 

Full 

9,216 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

Frame Relay 

Full 

12,288 

n/a 

n/a 

0% 

n/a 

n/a 

• 

VoIP 

Frame Relay 

Full 

15,360 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

Frame Relay 

Full 

18,432 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

Frame Relay 

Full 

43,008 

n/a 

n/a 

0% 

n/a 

n/a 

9 

VoIP over PPP link w/o RTP Header Compression 







VoIP 

PPP 

Full 

56 

n/a 

n/a 

0% 

n/a 

n/a 

9 

VoIP 

PPP 

Full 

64 

n/a 

n/a 

0% 

n/a 

n/a 

a 

VoIP 

PPP 

Full 

128 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

PPP 

Full 

256 

n/a 

n/a 

0% 

n/a 

n/a 

• 

VoIP 

PPP 

Full 

512 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

PPP 

Full 

768 

n/a 

n/a 

0% 

n/a 

n/a 

• 

VoIP 

PPP 

Full 

1,024 

n/a 

n/a 

0% 

n/a 

n/a 

• 

VoIP 

PPP 

Full 

1,536 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP in ATM/AAL-5 








• 

VoIP 

ATM (AAL-5) 

Full 

1,536 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

ATM (AAL-5) 

Full 

3,072 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

ATM (AAL-5) 

Full 

6,144 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

ATM (AAL-5) 

Full 

9,216 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

ATM (AAL-5) 

Full 

12,288 

n/a 

n/a 

0% 

n/a 

n/a 

• 

VoIP 

ATM (AAL-5) 

Full 

15,360 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

ATM (AAL-5) 

Full 

18,432 

n/a 

n/a 

0% 

n/a 

n/a 

V 

VoIP 

ATM (AAL-5) 

Full 

43,008 

n/a 

n/a 

0% 

n/a 

n/a 

• 

VoIP 

ATM (AAL-5) 

Full 

50,112 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

ATM (AAL-5) 

Full 

150,336 

n/a 

n/a 

0% 

n/a 

n/a 

• 

VoIP 

ATM (AAL-5) 

Full 

601,344 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

ATM (AAL-5) 

Full 

2,405,376 

n/a 

n/a 

0% 

n/a 

n/a 


VoIP 

ATM (AAL-5) 

Full 

4,810,752 

n/a 

n/a 

0% 

n/a 

n/a 

• 

• 

VoIP 

ATM (AAL-5) 

Full 

9,621,504 

n/a 

n/a 

0% 

n/a 

n/a 

• 

• 

p 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.723 (no VAD) <-!! 

G.723 is only available in increments <-* G.723 is only available in inert 

of 30ms packetization of 30ms packetization 

G.723 w/ 10ms Packetization G.723 w/ 20ms Packe 

Bandwidth Total Link Bandwidth Total 



over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

VoIP over Frame Relay w/ RTP Header Compression 






VoIP 

Frame Relay 

Full 

56 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

64 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

128 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

256 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

512 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

768 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

1,024 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

1,536 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

3,072 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

6,144 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

9,216 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

12,288 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

15,360 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

18,432 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

Frame Relay 

Full 

43,008 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP over PPP link w/ RTP Header Compression 






VoIP 

PPP 

Full 

56 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

PPP 

Full 

64 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

PPP 

Full 

128 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

PPP 

Full 

256 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

PPP 

Full 

512 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

PPP 

Full 

768 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

PPP 

Full 

1,024 

n/a 

n/a 

0% 

n/a 

n/a 

VoIP 

PPP 

Full 

1,536 

n/a 

n/a 

0% 

n/a 

n/a 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.723 (no VAD) 

over 

Full/Half 

Link Speed 

<-!! 

G.723 is only available in increments <-' 

of 30ms packetization 

G.723 w/ 10ms Packetization 

Bandwidth Total Link 

per trunk Bandwidth Utilization 

G.723 is only available in inert 
of 30ms packetization 

G.723 w/ 20ms Packe 

Bandwidth Total 

per trunk Bandwidth 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

Voice directly in Frame Relay 

VoFR Frame Relay 

Full 

56 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

64 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

128 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

256 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

512 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

768 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

1,024 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

1,536 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

3,072 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

6,144 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

9,216 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

12,288 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

15,360 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

18,432 

n/a 

n/a 

0% 

n/a 

n/a 

VoFR 

Frame Relay 

Full 

43,008 

n/a 

n/a 

0% 

n/a 

n/a 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.723 (no VAD) 


G.723 is only available in increments 
of 30ms packetization 

G.723 w/ 10ms Packetization 


<-!! 

<-' G.723 is only available in inert 
of 30ms packetization 

G.723 w/ 20ms Packe 



over 

Full/Half 

Link Speed 

Bandwidth 
per trunk 

Total 

Bandwidth 

Link 

Utilization 

Bandwidth 
per trunk 

Total 

Bandwidth 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

Voice directly in ATM/AAL-5 

VoATM ATM (AAL-5) 

Full 

1,536 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

3,072 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

6,144 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

9,216 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

12,288 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

15,360 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

18,432 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

43,008 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

50,112 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

150,336 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

601,344 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

2,405,376 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

4,810,752 

n/a 

n/a 

0% 

n/a 

n/a 

VoATM 

ATM (AAL-5) 

Full 

9,621,504 

n/a 

n/a 

0% 

n/a 

n/a 
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9 







■9 







9 

9 


Voice over IP (VoIP) Bandwidth Demand Calculator 








m 


<-!! 

Demand exceeds 100%! (can't do it!) <-!! 




ements <-* 

Demand exceeds 70% (caution) 

<-• 




tization 

G.723 wl 30ms Packetization 




Link 

Bandwidth 

Total 

Link 


o 


Utilization 

per trunk 

Bandwidth 

Utilization 


4 


(%) 

(bps) 

(bps) 

(%) 


4 


0% 

43,733 

174,933 

2% 


• 


0% 

43,733 

174,933 

0% 



0% 

21,867 

87,467 

0% 


w 

* 


0% 

18,667 

74,667 

133% <-!! 


W 


0% 

18,667 

74,667 

117% <-!! 


• 


0% 

18,667 

74,667 

58% 




0% 

18,667 

74,667 

29% 


• 


0% 

18,667 

74,667 

15% 




0% 

18,667 

74,667 

10% 




0% 

18,667 

74,667 

7% 


• 


0% 

18,667 

74,667 

5% 




0% 

18,667 

74,667 

2% 


• 


0% 

18,667 

74,667 

1% 


A 


0% 

18,667 

74,667 

1% 


• 


0% 

18,667 

74,667 

1% 


• 


0% 

18,667 

74,667 

0% 




0% 

18,667 

74,667 

0% 


• 


0% 

18,667 

74,667 

0% 


• 


0% 

19,200 

76,800 

137% <-!! 




0% 

19,200 

76,800 

120% <-!! 




0% 

19,200 

76,800 

60% 


w 


0% 

19,200 

76,800 

30% 


# 


0% 

19,200 

76,800 

15% 




0% 

19,200 

76,800 

10% 


• 


0% 

19,200 

76,800 

8% 


• 


0% 

19,200 

76,800 

5% 


• 


0% 

28,267 

113,067 

7% 




0% 

28,267 

113,067 

4% 


w 


0% 

28,267 

113,067 

2% 




0% 

28,267 

113,067 

1% 




0% 

28,267 

113,067 

1% 


• 


0% 

28,267 

113,067 

1% 




0% 

28,267 

113,067 

1% 


w 


0% 

28,267 

113,067 

0% 


A 


0% 

28,267 

113,067 

0% 




0% 

28,267 

113,067 

0% 


• 


0% 

28,267 

113,067 

0% 


A 


0% 

28,267 

113,067 

0% 




0% 

28,267 

113,067 

0% 


• 

A 


0% 

28,267 

113,067 

0% 


.^r 

• 

By: Matthew F. Michels 


Ver. 2.1, 3/8/2001 


Page 29 of 75 

£ 

• 








By: Matthew F. Michels 


Voice over IP (VoIP) Bandwidth Demand Calculator 

<-!! 

ements <-* 

Demand exceeds 100%! (can't do it!) 
Demand exceeds 70% (caution) 

tization 

G.723 w/ 30ms Packetization 

Link 

Bandwidth 

Total 

Link 

Utilization 

per trunk 

Bandwidth 

Utilization 

(%) 

(bps) 

(bps) 

(%) 

0% 

9,333 

37,333 

67% 

0% 

9,333 

37,333 

58% 

0% 

9,333 

37,333 

29% 

0% 

9,333 

37,333 

15% 

0% 

9,333 

37,333 

7% 

0% 

9,333 

37,333 

5% 

0% 

9,333 

37,333 

4% 

0% 

9,333 

37,333 

2% 

0% 

9,333 

37,333 

1% 

0% 

9,333 

37,333 

1% 

0% 

9,333 

37,333 

0% 

0% 

9,333 

37,333 

0% 

0% 

9,333 

37,333 

0% 

0% 

9,333 

37,333 

0% 

0% 

9,333 

37,333 

0% 

0% 

9,867 

39,467 

70% 

0% 

9,867 

39,467 

62% 

0% 

9,867 

39,467 

31% 

0% . 

9,867 

39,467 

15% 

0% 

9,867 

39,467 

8% 

0% 

9,867 

39,467 

5% 

0% 

9,867 

39,467 

4% 

0% 

9,867 

39,467 

3% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


<-!! Demand exceeds 100%! (can't do it!) < 


ements 

<-* 

Demand exceeds 70% (caution) 

< 

tization 


G.723 w/ 30ms Packetization 

Link 


Bandwidth 

Total 

Link 

Utilization 

per trunk 

Bandwidth 

Utilization 

(%) 


(bps) 

(bps) 

(%) 


0% 

8,800 

35,200 

63% 


0% 

8,800 

35,200 

55% 


0% 

8,800 

35,200 

28% 


0% 

8,800 

35,200 

14% 


0% 

8,800 

35,200 

7% 


0% 

8,800 

35,200 

5% 


0% 

8,800 

35,200 

3% 


0% 

8,800 

35,200 

2% 


0% 

8,800 

35,200 

1% 


0% 

8,800 

35,200 

1%* 


0% 

8,800 

35,200 

0% 


0% 

8,800 

35,200 

0% 


0% 

8,800 

35,200 

0% 


0% 

8,800 

35,200 

0% 


0% 

8,800 

35,200 

0% 


By: Matthew F. Michel? 


Ver. 2.1, 3/8/2001 


Voice over IP (VoIP) Bandwidth Demand Calculator 


<-!! Demand exceeds 100%! (can't do it!) <-!! 
ements <-* Demand exceeds 70% (caution) <-* 

tization G.723 w/ 30ms Packetization 


Link 

Bandwidth 

Total 

Link 

Utilization 

per trunk 

Bandwidth 

Utilization 

(%) 

(bps) 

(bps) 

(%) 

0% 

14,133 

56,533 

4% 

0% 

14,133 

56,533 

2% 

0% 

14,133 

56,533 

1% 

0% 

14,133 

56,533 

1% 

0% 

14,133 

56,533 

0% 

0% 

14,133 

56,533 

0% 

0% 

14,133 

56,533 

0% 

0% 

14,133 

56,533 

0% 

0% 

14,133 

56,533 

0% 

• 0% 

14,133 

56,533 

0% 

0% 

14,133 

56,533 

0% 

0% 

14,133 

56,533 

0% 

0% 

14,133 

56,533 

0% 

0% 

14,133 

56,533 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can’t do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) <-• 

G.723 w/ 40ms Packetization G.723 w/ 60ms Packetization 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

n/a 

n/a 

0% 

28,267 

113,067 

1% 

n/a 

n/a 

0% 

28,267 

113,067 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

12,533 

50,133 

90% <-’ 

n/a 

n/a 

0% 

12,533 

50,133 

78% <-' 

n/a 

n/a 

0% 

12,533 

50,133 

39% 

n/a 

n/a 

0% 

12,533 

50,133 

20% 

n/a 

n/a 

0% 

12,533 

50,133 

10% 

n/a 

n/a 

0% 

12,533 

50,133 

7% 

n/a 

n/a 

0% 

12,533 

50,133 

5% 

n/a 

n/a 

0% 

12,533 

50,133 

3% 

n/a 

n/a 

0% 

12,533 

50,133 

2% 

n/a 

n/a 

0% 

12,533 

50,133 

1% 

n/a 

n/a 

0% 

12,533 

50,133 

1% 

n/a 

n/a 

0% 

12,533 

50,133 

0% 

n/a 

n/a 

0% 

12,533 

50,133 

0% 

n/a 

n/a 

0% 

12,533 

50,133 

0% 

n/a 

n/a 

0% 

12,533 

50,133 

0% 

n/a 

n/a 

0% 

12,800 

51,200 

91% <-' 

n/a 

n/a 

0% 

12,800 

51,200 

80% 

n/a 

n/a 

0% 

12,800 

51,200 

40% 

n/a 

n/a 

0% 

12,800 

51,200 

20% 

n/a 

n/a 

0% 

12,800 

51,200 

10% 

n/a 

n/a 

0% 

12,800 

51,200 

7% 

n/a 

n/a 

0% 

12,800 

51,200 

5% 

n/a 

n/a 

0% 

12,800 

51,200 

3% 

n/a 

n/a 

0% 

14,133 

56,533 

4% 

n/a 

n/a 

0% 

14,133 

56,533 

2% 

n/a 

n/a 

0% 

14,133 

56,533 

1% 

n/a 

n/a 

0% 

14,133 

56,533 

1% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 


P 

P 

P 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-' 

Demand exceeds 100%! (can't do it!) 
Demand exceeds 70% (caution) 

G.723 w/ 40ms Packetization 

G.723 w/ 60ms Packetization 

Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

n/a 

n/a 

0% 

7,867 

31,467 

56% 

n/a 

n/a 

0% 

7,867 

31,467 

49% 

n/a 

n/a 

0% 

7,867 

31,467 

25% 

n/a 

n/a 

0% 

7,867 

31,467 

12% 

n/a 

n/a 

0% 

7,867 

31,467 

6% 

n/a 

n/a 

0% 

7,867 

31,467 

4% 

n/a 

n/a 

0% 

7,867 

31,467 

3% 

n/a 

n/a 

0% 

7,867 

31,467 

2% 

n/a 

n/a 

0% 

7,867 

31,467 

1% 

n/a 

n/a 

0% 

7,867 

31,467 

1% 

n/a 

n/a 

0% 

7,867 

31,467 

0% 

n/a 

n/a 

0% 

7,867 

31,467 

0% 

n/a 

n/a 

0% 

7,867 

31,467 

0% 

n/a 

n/a 

0% 

7,867 

31,467 

0% 

n/a 

n/a 

0% 

7,867 

31,467 

0% 

n/a 

n/a 

0% 

8,133 

32,533 

58% 

n/a 

n/a 

0% 

8,133 

32,533 

51% 

n/a 

n/a 

0% 

8,133 

32,533 

25% 

n/a 

n/a 

0% 

8,133 

32,533 

13% 

n/a 

n/a 

0% 

8,133 

32,533 

6% 

n/a 

n/a 

0% 

8,133 

32,533 

4% 

n/a 

n/a 

0% 

8,133 

32,533 

3% 

n/a 

n/a 

0% 

8,133 

32,533 

2% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 100%! (can't do it!) 

Demand exceeds 70% (caution) 

<-• 

Demand exceeds 70% (caution) 


G.723 w/ 40ms Packetization 

G.723 w/ 60ms Packetization 

Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

n/a 

n/a 

0% 

7,600 

30,400 

54% 

n/a 

n/a 

0% 

7,600 

30,400 

48% 

n/a 

n/a 

0% 

7,600 

30,400 

24% 

n/a 

n/a 

0% 

7,600 

30,400 

12% 

n/a 

n/a 

0% 

7,600 

30,400 

6% 

n/a 

n/a 

0% 

7,600 

30,400 

4% 

n/a 

n/a 

0% 

7,600 

30,400 

3% 

n/a 

n/a 

0% 

7,600 

30,400 

2% 

n/a 

n/a 

0% 

7,600 

30,400 

1% 

n/a 

n/a 

0% 

7.600 

30,400 

0% 

n/a 

n/a 

0% 

7,600 

30,400 

0% 

n/a 

n/a 

0% 

7,600 

30,400 

0% 

n/a 

n/a 

0% 

7,600 

30,400 

0% 

n/a 

n/a 

0% 

7,600 

30,400 

0% 

n/a 

n/a 

0% 

7,600 

30,400 

0% 



By: Matthew F. Michels 


Ver. 2.1, 3/8/2001 


Page 35 of 75 



Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) 

<-!! 

Demand exceeds 100%! (can't do it!) 


Demand exceeds 70% (caution) 


<-• 

Demand exceeds 70% (caution) 



G.723 w/ 40ms Packetization 


G.723 w/ 60ms Packetization 


Bandwidth 

Total 

Link 


Bandwidth 

Total 

Link 


per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 


(bps) 

(bps) 

(%) 


n/a 

n/a 


0% 

14,133 

56,533 


4% 

n/a 

n/a 


0% 

14,133 

56,533 


2% 

n/a 

n/a 


0% 

14,133 

56,533 


1% 

n/a 

n/a 


0% 

14,133 

56,533 


1% 

n/a 

n/a 


0% 

14,133 

56,533 


0% 

n/a 

n/a 


0% 

14,133 

56,533 


0% 

n/a 

n/a 


0% 

14,133 

56,533 


0% 

n/a 

n/a 


0% 

14,133 

56,533 


0% 

n/a 

n/a 


0% 

14,133 

56,533 


0% 

n/a 

n/a 


0% 

14,133 

56,533 


0% 

n/a 

n/a 


0% 

14,133 

56,533 


0% 

n/a 

n/a 


0% 

14,133 

56,533 


0% 

n/a 

n/a 


0% 

14,133 

56,533 


0% 

n/a 

n/a 


0% 

14,133 

56,533 


0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.711 (w/ VAD) Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (car 

Demand exceeds 70% (caution) <-■ Demand exceeds 70% (cautic 






G.711 w/ 10ms Packetization w/ VAD 

G.711 w/ 20ms Packetizat 





Bandwidth 

Total 

Link 

Bandwidth 

Total 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

VoIP over Ethernet LAN 








VoIP 

802.3 

Half 

10,000 

220,800 

883,200 

9% 

174,400 

697,600 

VoIP 

802.3 

Half 

100,000 

220,800 

883,200 

1% 

174,400 

697,600 

VoIP 

802.3 

Full 

100,000 

110,400 

441,600 

0% 

87,200 

348,800 

VoIP over Frame Relay w/o RTP Header Compression 






VoIP 

Frame Relay 

Full 

56 

100,800 

403,200 

720% <-!! 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

64 

100,800 

403,200 

630% <-!! 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

128 

100,800 

403,200 

315% <-!! 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

256 

100,800 

403,200 

158% <-!! 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

512 

100,800 

403,200 

79% <-' 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

768 

100,800 

403,200 

53% 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

1,024 

100,800 

403,200 

39% 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

1,536 

100,800 

403,200 

26% 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

3,072 

100,800 

403,200 

13% 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

6,144 

100.800 

403,200 

7% 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

9,216 

100,800 

403,200 

4% 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

12,288 

100,800 

403,200 

3% 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

15,360 

100,800 

403,200 

3% 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

18,432 

100,800 

403,200 

2% 

82,400 

329,600 

VoIP 

Frame Relay 

Full 

43,008 

100,800 

403,200 

1% 

82,400 

329,600 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.711 (w/VAD) Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (car 

Demand exceeds 70% (caution) <-’ Demand exceeds 70% (cautic 

G.711 w/ 10ms Packetization w/ VAD G.711 w/ 20ms Packetizat 






Bandwidth 

Total 

Link 

Bandwidth 

Total 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

VoIP over PPP link w/o RTP Header Compression 






VoIP 

ppp 

Full 

56 

102,400 

409,600 

731% <-!! 

83,200 

332,800 

VoIP 

ppp 

Full 

64 

102,400 

409,600 

640% <-!! 

83,200 

332,800 

VoIP 

ppp 

Full 

128 

102,400 

409,600 

320% <-!! 

83,200 

332,800 

VoIP 

ppp 

Full 

256 

102,400 

409,600 

160% <-!! 

83,200 

332,800 

VoIP 

ppp 

Full 

512 

102,400 

409,600 

80% <-’ 

83,200 

332,800 

VoIP 

ppp 

Full 

768 

102,400 

409,600 

53% 

83,200 

332,800 

VoIP 

ppp 

Full 

1,024 

102,400 

409,600 

40% 

83,200 

332,800 

VoIP 

ppp 

Full 

1,536 

102,400 

409,600 

27% 

83,200 

332,800 

VoIP in ATM/AAL-5 








VoIP 

ATM (AAL-5) 

Full 

1,536 

127,200 

508,800 

33% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

3,072 

127,200 

508,800 

17% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

6,144 

127,200 

508,800 

8% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

9,216 

127,200 

508,800 

6% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

12,288 

127,200 

508,800 

4% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

15,360 

127,200 

508,800 

3% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

18,432 

127,200 

508,800 

3% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

43,008 

127,200 

508,800 

1% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

50,112 

127,200 

508,800 

1% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

150,336 

127,200 

508,800 

0% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

601,344 

127,200 

508,800 

0% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

2,405,376 

127,200 

508,800 

0% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

4,810,752 

127,200 

508,800 

0% 

106,000 

424,000 

VoIP 

ATM (AAL-5) 

Full 

9,621,504 

127,200 

508,800 

0% 

106,000 

424,000 
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Voice over IP (VoIP) Bandwidth Demand Calculator 



G.711 (w/VAD) 



Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 100%! (car 





Demand exceeds 70% (caution) 


Demand exceeds 70% (cautic 





G.711 w/ 10ms Packetization w/ VAD 

G.711 w/ 20ms Packetizal 





Bandwidth 

Total 

Link 

Bandwidth 

Total 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

VoIP over Frame Relay w/ RTP Pleader Compression 






VoIP 

Frame Relay 

Full 

56 

72,800 

291,200 

520% <-!! 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

64 

72,800 

291,200 

455% <-!! 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

128 

72,800 

291,200 

228% <-!! 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

256 

72,800 

291,200 

114% <-!! 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

512 

72,800 

291,200 

57% 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

768 

72,800 

291,200 

38% 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

1,024 

72,800 

291,200 

28% 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

1,536 

72,800 

291,200 

19% 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

3,072 

72,800 

291,200 

9% 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

6,144 

72,800 

291,200 

5% 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

9,216 

72,800 

291,200 

3% 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

12,288 

72,800 

291,200 

2% 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

15,360 

72,800 

291,200 

2% 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

18,432 

72,800 

291,200 

2% 

68,400 

273,600 

VoIP 

Frame Relay 

Full 

43,008 

72,800 

291,200 

1% 

68,400 

273,600 

VoIP over PPP link w/ RTP Pleader Compression 






VoIP 

PPP 

Full 

56 

74,400 

297,600 

531% <-!! 

69,200 

276,800 

VoIP 

PPP 

Full 

64 

74,400 

297,600 

465% <-!! 

69,200 

276,800 

VoIP 

PPP 

Full 

128 

74,400 

297,600 

233% <-!! 

69,200 

276,800 

VoIP 

PPP 

Full 

256 

74,400 

297,600 

116% <-!! 

69,200 

276,800 

VoIP 

PPP 

Full 

512 

74,400 

297,600 

58% 

69,200 

276,800 

VoIP 

PPP 

Full 

768 

74,400 

297,600 

39% 

69,200 

276,800 

VoIP 

PPP 

Full 

1,024 

74,400 

297,600 

29% 

69,200 

276,800 

VoIP 

PPP 

Full 

1,536 

74,400 

297,600 

19% 

69,200 

276,800 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.711 (w/VAD) Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (car 

Demand exceeds 70% (caution) <-’ Demand exceeds 70% (cautic 






G.711 w/ 10ms Packetization w/ VAD 

G.711 w/ 20ms Packetizat 





Bandwidth 

Total 

Link 

Bandwidth 

Total 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

Voice directly 

in Frame Relay 








VoFR 

Frame Relay 

Full 

56 

71,200 

284,800 

509% <-!! 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

64 

71,200 

284,800 

445% <-!! 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

128 

71,200 

284,800 

223% <-!! 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

256 

71,200 

284,800 

111% <-!! 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

512 

71,200 

284,800 

56% 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

768 

71,200 

284,800 

37% 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

1,024 

71,200 

284,800 

28% 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

1,536 

71,200 

284,800 

19% 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

3,072 

71,200 

284,800 

9% 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

6,144 

71,200 

284,800 

5% 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

9,216 

71,200 

284,800 

3% 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

12,288 

71,200 

284,800 

2% 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

15,360 

71,200 

284,800 

2% 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

18,432 

71,200 

284,800 

2% 

67,600 

270,400 

VoFR 

Frame Relay 

Full 

43,008 

71,200 

284,800 

1% 

67,600 

270,400 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.711 (w/VAD) Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (car 

Demand exceeds 70% (caution) <-' Demand exceeds 70% (cautic 

G.711 w/ 10ms Packetization w/ VAD G.711 w/ 20ms Packetizat 



over 

Full/Half 

Link Speed 

Bandwidth 
per trunk 

Total 

Bandwidth 

Link 

Utilization 

Bandwidth 
per trunk 

Total 

Bandwidth 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

Voice directly in ATM/AAL-5 

VoATM ATM (AAL-5) 

Full 

1,536 

84,800 

339,200 

22% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

3,072 

84,800 

339,200 

11% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

6,144 

84,800 

339,200 

6% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

9,216 

84,800 

339,200 

4% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

12,288 

84,800 

339,200 

3% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

15,360 

84,800 

339,200 

2% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

18,432 

84,800 

339,200 

2% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

43,008 

84,800 

339,200 

1% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

50,112 

84,800 

339,200 

1% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

150,336 

84,800 

339,200 

0% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

601,344 

84,800 

339,200 

0% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

2,405,376 

84,800 

339,200 

0% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

4,810,752 

84,800 

339,200 

0% 

84,800 

339,200 

VoATM 

ATM (AAL-5) 

Full 

9,621,504 

84,800 

339,200 

0% 

84,800 

339,200 


By: Matthew F. Michels 


Ver. 2.1, 3/8/2001 


Page 41 of 75 




Voice over IP (VoIP) Bandwidth Demand Calculator 


Vt do it!) <-!! 

Demand exceeds 100%! (can't do it!) <-!! 

in) <-* 

Demand exceeds 70% (caution) 

<-* 

iion w/ VAD 

G.711 w/ 30ms Packetization w/ VAD 

Link 

Bandwidth 

Total 

Link 

Utilization 

per trunk 

Bandwidth 

Utilization 

(%) 

(bps) 

(bps) 

(%) 

7% 

158,933 

635,733 

6% 

1% 

158,933 

635,733 

1% 

0% 

79,467 

317,867 

0% 

589% <-!! 

76,267 

305,067 

545% <-!! 

515% <-!! 

76,267 

305,067 

477% <-!! 

258% <-!! 

76,267 

305,067 

238% <-!! 

129% <-!! 

76,267 

305,067 

119% <-!! 

64% 

76,267 

305,067 

60% 

43% 

76,267 

305,067 

40% 

32% 

76,267 

305,067 

30% 

21% 

76,267 

305,067 

20% 

11% 

76,267 

305,067 

10% 

5% 

76,267 

305,067 

5% 

4% 

76,267 

305,067 

3% 

3% 

76,267 

305,067 

2% 

2% 

76,267 

305,067 

2% 

2% 

76,267 

305,067 

2% 

1% 

76,267 

305,067 

1% 


By: Matthew F. Michels 


Ver. 2.1, 3/8/2001 


Page 42 of 75 





f 

f 

? 


Voice over IP (VoIP) Bandwidth Demand Calculator 



Vt do it!) <-!! 

Demand exceeds 100%! (can't do it!) <-!! 

in) <-* 

Demand exceeds 70% (caution) 

<-* 

lion w/ VAD 

G.711 w/ 30ms Packetization w/ VAD 

Link 

Bandwidth 

Total 

Link 

Utilization 

per trunk 

Bandwidth 

Utilization 

(%) 

(bps) 

(bps) 

(%) 

594% <-!! 

76,800 

307,200 

549% <-!! 

520% <-!! 

76,800 

307,200 

480% <-!! 

260% <-!! 

76,800 

307,200 

240% <-!! 

130% <-!! 

76,800 

307,200 

120% <-!! 

65% 

76,800 

307,200 

60% 

43% 

76,800 

307,200 

40% 

33% 

76,800 

307,200 

30% 

22% 

76,800 

307,200 

20% 

28% 

84,800 

339,200 

22% 

14% 

84,800 

339,200 

11% 

7% 

84,800 

339,200 

6% 

5% 

84,800 

339,200 

4% 

3% 

84,800 

339,200 

3% 

3% 

84,800 

339,200 

2% 

2% 

84,800 

339,200 

2% 

1% 

84,800 

339,200 

1% 

1% 

84,800 

339,200 

1% 

0% 

84,800 

339,200 

0% 

0% 

84,800 

339,200 

0% 

0% 

84,800 

339,200 

0% 

0% 

84,800 

339,200 

0% 

0% 

84,800 

339,200 

0% 


P 

P 

P 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Vt do it!) <-!! 

Demand exceeds 100%! (can't do it!) <-!! 

}n) <-' 

Demand exceeds 70% (caution) 

<-• 

tion w/ VAD 

G.711 w/ 30ms Packetization w/ VAD 

Link 

Bandwidth 

Total 

Link 

Utilization 

per trunk 

Bandwidth 

Utilization 

(%) 

(bps) 

(bps) 

(%) 

489% <-!! 

66,933 

267,733 

478% <-!! 

428% <-!! 

66,933 

267,733 

418% <-!! 

214% <-!! 

66,933 

267,733 

209% <-!! 

107% <-!! 

66,933 

267,733 

105% <-!! 

53% 

66,933 

267,733 

52% 

36% 

66,933 

267,733 

35% 

27% 

66,933 

267,733 

26% 

18% 

66,933 

267,733 

17% 

9% 

66,933 

267,733 

9% 

4% 

66,933 

267,733 

4% 

3% 

66,933 

267,733 

3% 

2% 

66,933 

267,733 

2% 

2% 

66,933 

267,733 

2% 

1% 

66,933 

267,733 

1% 

1% 

66,933 

267,733 

1% 

494% <-!! 

67,467 

269,867 

482% <-!! 

433% <-!! 

67,467 

269,867 

422% <-!! 

216% <-!! 

67,467 

269,867 

211% <-!! 

108% <-!! 

67,467 

269,867 

105% <-!! 

54% 

67,467 

269,867 

53% 

36% 

67,467 

269,867 

35% 

27% 

67,467 

269,867 

26% 

18% 

67,467 

269,867 

18% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


I't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

jn) <-* Demand exceeds 70% (caution) <-* 

tion w/ VAD G.711 w/ 30ms Packetization w/ VAD 


Link 

Bandwidth 

Total 

Link 

Utilization 

per trunk 

Bandwidth 

Utilization 

(%) 

(bps) 

(bps) 

(%) 

483% <-!! 

66,400 

265,600 

474% <-!! 

423% <-!! 

66,400 

265,600 

415% <-!! 

211% <-!! 

66,400 

265,600 

208% <-!! 

106% <-!! 

66,400 

265,600 

104% <-!! 

53% 

66,400 

265,600 

52% 

35% 

66,400 

265,600 

35% 

26% 

66,400 

265,600 

26% 

18% 

66,400 

265,600 

17% 

9% 

66,400 

265,600 

9% 

4% 

66,400 

265,600 

4% 

3% 

66,400 

265,600 

3% 

2% 

66,400 

265,600 

2% 

2% 

66,400 

265,600 

2% 

1% 

66,400 

265,600 

1% 

1% 

66,400 

265,600 

1% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


it do it!) <-!! 

in) <-• 

Demand exceeds 100%! (can't do it!) 
Demand exceeds 70% (caution) 

don w/ VAD 

G.711 w / 30ms Packetization w/ VAD 

Link 

Bandwidth 

Total 

Link 

Utilization 

per trunk 

Bandwidth 

Utilization 

(%) 

(bps) 

(bps) 

(%) 

22% 

84,800 

339,200 

22% 

11% 

84,800 

339,200 

11% 

6% 

84,800 

339,200 

6% 

4% 

84,800 

339,200 

4% 

3% 

84,800 

339,200 

3% 

2% 

84,800 

339,200 

2% 

2% 

84,800 

339,200 

2% 

1% 

84,800 

339,200 

1% 

1% 

84,800 

339,200 

1% 

0% 

84,800 

339,200 

0% 

0% 

84,800 

339,200 

0% 

0% 

84,800 

339,200 . 

0% 

0% 

84,800 

339,200 

0% 

0% 

84,800 

339,200 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) <-' 

G.711 w/ 40ms Packetization w/ VAD G.711 w/ 60ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

151,200 

604,800 

6% 

143,467 

573,867 

6% 

151,200 

604,800 

1% 

143,467 

573,867 

1% 

75,600 

302,400 

0% 

71,733 

286,933 

0% 

73,200 

292,800 

523% <-!! 

70,133 

280,533 

501% <-!! 

73,200 

292,800 

458% <-!! 

70,133 

280,533 

438% <-!! 

73,200 

292,800 

229% <-!! 

70,133 

280,533 

219% <-!! 

73,200 

292,800 

114% <-!! 

70,133 

280,533 

110% <-!! 

73,200 

292,800 

57% 

70,133 

280,533 

55% 

73,200 

292,800 

38% 

70,133 

280,533 

37% 

73,200 

292,800 

29% 

70,133 

280,533 

27% 

73,200 

292,800 

19% 

70,133 

280,533 

18% 

73,200 

292,800 

10% 

70,133 

280,533 

9% 

73,200 

292,800 

5% 

70,133 

280,533 

5% 

73,200 

292,800 

3% 

70,133 

280,533 

3% 

73,200 

292,800 

2% 

70,133 

280,533 

2% 

73,200 

292,800 

2% 

70,133 

280,533 

2% 

73,200 

292,800 

2% 

70,133 

280,533 

2% 

73,200 

292,800 

1% 

70,133 

280,533 

1% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-• Demand exceeds 70% (caution) <-’ 

G.711 w/ 40ms Packetization w/ VAD G.711 w/ 60ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

73,600 

294,400 

526% <-!! 

70,400 

281,600 

503% <-!! 

73,600 

294,400 

460% <-!! 

70,400 

281,600 

440% <-!! 

73,600 

294,400 

230% <-!! 

70,400 

281,600 

220% <-!! 

73,600 

294,400 

115% <-!! 

70,400 

281,600 

110% <-!! 

73,600 

294,400 

58% 

70,400 

281,600 

55% 

73,600 

294,400 

38% 

70,400 

281,600 

37% 

73,600 

294,400 

29% 

70,400 

281,600 

28% 

73,600 

294,400 

19% 

70,400 

281,600 

18% 

84,800 

339,200 

22% 

77,733 

310,933 

20% 

84,800 

339,200 

11% 

77,733 

310,933 

10% 

84,800 

339,200 

6% 

77,733 

310,933 

5% 

84,800 

339,200 

4% 

77,733 

310,933 

3% 

84,800 

339,200 

3% 

77,733 

310,933 

3% 

84,800 

339,200 

2% 

77,733 

310,933 

2% 

84,800 

339,200 

2% 

77,733 

310,933 

2% 

84,800 

339,200 

1% 

77,733 

310,933 

1% 

84,800 

339,200 

1% 

77,733 

310,933 

1% 

84,800 

339,200 

0% 

77,733 

310,933 

0% 

84,800 

339,200 

0% 

77,733 

310,933 

0% 

84,800 

339,200 

0% 

77,733 

310,933 

0% 

84,800 

339,200 

0% 

77,733 

310,933 

0% 

84,800 

339,200 

0% 

77,733 

310,933 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 



Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-• Demand exceeds 70% (caution) <-* 

G.711 w/ 40ms Packetization w/ VAD G.711 w/ 60ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

66,200 

264,800 

473% <-!! 

65,467 

261,867 

468% <-!! 

66,200 

264,800 

414% <-!! 

65,467 

261,867 

409% <-!! 

66,200 

264,800 

207% <-!! 

65,467 

261,867 

205% <-!! 

66,200 

264,800 

103% <-!! 

65,467 

261,867 

102% <-!! 

66,200 

264,800 

52% 

65,467 

261,867 

51% 

66,200 

264,800 

34% 

65,467 

261,867 

34% 

66,200 

264,800 

26% 

65,467 

261,867 

26% 

66,200 

264,800 

17% 

65,467 

261,867 

17% 

66,200 

264,800 

9% 

65,467 

261,867 

9% 

66,200 

264,800 

4% 

65,467 

261,867 

4% 

66,200 

264,800 

3% 

65,467 

261,867 

3% 

66,200 

264,800 

2% 

65,467 

261,867 

2% 

66,200 

264,800 

2% 

65,467 

261,867 

2% 

66,200 

264,800 

1% 

65,467 

261,867 

1% 

66,200 

264,800 

1% 

65,467 

261,867 

1% 

66,600 

266,400 

476% <-!! 

65,733 

262,933 

470% <-!! 

66,600 

266,400 

416% <-!! 

65,733 

262,933 

411% <-U 

66,600 

266,400 

208% <-!! 

65,733 

262,933 

205% <-!! 

66,600 

266,400 

104% <-!! 

65,733 

262,933 

103% <-!! 

66,600 

266,400 

52% 

65,733 

262,933 

51% 

66,600 

266,400 

35% 

65,733 

262,933 

34% 

66,600 

266,400 

26% 

65,733 

262,933 

26% 

66,600 

266,400 

17% 

65,733 

262,933 

17% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-• Demand exceeds 70% (caution) <-’ 

G.711 w/ 40ms Packetization w/ VAD G.711 w/ 60ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

65,800 

263,200 

470% <-!! 

65,200 

260,800 

466% <-!! 

65,800 

263,200 

411% <-!! 

65,200 

260,800 

408% <-!! 

65,800 

263,200 

206% <-!! 

65,200 

260,800 

204% <-!! 

65,800 

263,200 

103% <-!! 

65,200 

260,800 

102% <-!! 

65,800 

263,200 

51% 

65,200 

260,800 

51% 

65,800 

263,200 

34% 

65,200 

260,800 

34% 

65,800 

263,200 

26% 

65,200 

260,800 

25% 

65,800 

263,200 

17% 

65,200 

260,800 

17% 

65,800 

263,200 

9% 

65,200 

260,800 

8% 

65,800 

263,200 

4% 

65,200 

260,800 

4% 

65,800 

263,200 

3% 

65,200 

260,800 

3% 

65,800 

263,200 

2% 

65,200 

260,800 

2% 

65,800 

263,200 

2% 

65,200 

260,800 

2% 

65,800 

263,200 

1% 

65,200 

260,800 

1% 

65,800 

263,200 

1% 

65,200 

260,800 

1% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) <-* 


G.711 w/ 40ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

74,200 

296,800 

19% 

74,200 

296,800 

10% 

74,200 

296,800 

5% 

74,200 

296,800 

3% 

74,200 

296,800 

2% 

74,200 

296,800 

2% 

74,200 

296,800 

2% 

74,200 

296,800 

1% 

74,200 

296,800 

1% 

74,200 

296,800 

0% 

74,200 

296,800 

0% 

74,200 

296,800 

0% 

74,200 

296,800 

0% 

74,200 

296,800 

0% 


G.711 w/ 60ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

77,733 

310,933 

20% 

77,733 

310,933 

10% 

77,733 

310,933 

5% 

77,733 

310,933 

3% 

77,733 

310,933 

3% 

77,733 

310,933 

2% 

77,733 

310,933 

2% 

77,733 

310,933 

1% 

77,733 

310,933 

1% 

77,733 

310,933 

0% 

77,733 

310,933 

0% 

77,733 

310,933 

0% 

77,733 

310,933 

0% 

77,733 

310,933 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.729 (w / VAD) Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* 




• 


G.729 w/ 10ms Packetization w/ VAD 





Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

VoIP over Ethernet LAN 






VoIP 

802.3 

Half 

10.000 

108,800 

435,200 

4% 

VoIP 

802.3 

Half 

100,000 

108,800 

435,200 

0% 

VoIP 

802.3 

Full 

100,000 

54,400 

217,600 

0% 

VoIP over Frame Relay w/o RTP Header Compression 




VoIP 

Frame Relay 

Full 

56 

44,800 

179,200 

320% <-!! 

VoIP 

Frame Relay 

Full 

64 

44,800 

179,200 

280% <-!! 

VoIP 

Frame Relay 

Full 

128 

44,800 

179,200 

140% <-!! 

VoIP 

Frame Relay 

Full 

256 

44,800 

179,200 

70% <-• 

VoIP 

Frame Relay 

Full 

512 

44,800 

179.200 

35% 

VoIP 

Frame Relay 

Full 

768 

44,800 

179,200 

23% 

VoIP 

Frame Relay 

Full 

1,024 

44,800 

179,200 

18% 

VoIP 

Frame Relay 

Full 

1,536 

44,800 

179,200 

12% 

VoIP 

Frame Relay 

Full 

3,072 

44,800 

179,200 

6% 

VoIP 

Frame Relay 

Full 

6,144 

44,800 

179,200 

3% 

VoIP 

Frame Relay 

Full 

9,216 

44,800 

179,200 

2% 

VoIP 

Frame Relay 

Full 

12,288 

44,800 

179,200 

1% 

VoIP 

Frame Relay 

Full 

15,360 

44,800 

179,200 

1% 

VoIP 

Frame Relay 

Full 

18,432 

44,800 

179,200 

1% 

VoIP 

Frame Relay 

Full 

43,008 

44,800 

179,200 

0% 

VoIP over PPP link w/o RTP Header Compression 




VoIP 

PPP 

Full 

56 

46,400 

185,600 

331% <-!! 

VoIP 

PPP 

Full 

64 

46,400 

185,600 

290% <-!! 

VoIP 

PPP 

Full 

128 

46.400 

185,600 

145% <-!! 

VoIP 

PPP 

Full 

256 

46,400 

185,600 

73% <-* 

VoIP 

PPP 

Full 

512 

46,400 

185,600 

36% 

VoIP 

PPP 

Full 

768 

46,400 

185,600 

24% 

VoIP 

PPP 

Full 

1,024 

46,400 

185,600 

18% 

VoIP 

PPP 

Full 

1,536 

46,400 

185,600 

12% 

VoIP in ATM/AAL-5 






VoIP 

ATM (AAL-5) 

Full 

1,536 

84,800 

339,200 

22% 

VoIP 

ATM (AAL-5) 

Full 

3,072 

84,800 

339,200 

11% 

VoIP 

ATM (AAL-5) 

Full 

6,144 

84,800 

339,200 

6% 

VoIP 

ATM (AAL-5) 

Full 

9,216 

84,800 

339,200 

4% 

VoIP 

ATM (AAL-5) 

Full 

12,288 

84,800 

339,200 

3% 

VoIP 

ATM (AAL-5) 

Full 

15,360 

84,800 

339,200 

2% 

VoIP 

ATM (AAL-5) 

Full 

18,432 

84,800 

339,200 

2% 

VoIP 

ATM (AAL-5) 

Full 

43,008 

84,800 

339,200 

1% 

VoIP 

ATM (AAL-5) 

Full 

50,112 

84,800 

339,200 

1% 

VoIP 

ATM (AAL-5) 

Full 

150,336 

84,800 

339,200 

0% 

VoIP 

ATM (AAL-5) 

Full 

601,344 

84,800 

339,200 

0% 

VoIP 

ATM (AAL-5) 

Full 

2,405,376 

84,800 

339,200 

0% 

VoIP 

ATM (AAL-5) 

Full 

4,810,752 

84,800 

339,200 

0% 

VoIP 

ATM (AAL-5) 

Full 

9,621,504 

84,800 

339,200 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.729 (w / VAD) Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* 






G.729 w / 10ms Packetization w/ VAD 





Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

VoIP over Frame Relay w/ RTP Header Compression 




VoIP 

Frame Relay 

Full 

56 

16,800 

67,200 

120% <-!! 

VoIP 

Frame Relay 

Full 

64 

16,800 

67,200 

105% <-!! 

VoIP 

Frame Relay 

Full 

128 

16,800 

67,200 

53% 

VoIP 

Frame Relay 

Full 

256 

16,800 

67,200 

26% 

VoIP 

Frame Relay 

Full 

512 

16,800 

67,200 

13% 

VoIP 

Frame Relay 

Full 

768 

16,800 

67,200 

9% 

VoIP 

Frame Relay 

Full 

1,024 

16,800 

67,200 

7% 

VoIP 

Frame Relay 

Full 

1,536 

16,800 

67,200 

4% 

VoIP 

Frame Relay 

Full 

3,072 

16,800 

67,200 

2% 

VoIP 

Frame Relay 

Full 

6,144 

16,800 

67,200 

1% 

VoIP 

Frame Relay 

Full 

9,216 

16,800 

67,200 

1% 

VoIP 

Frame Relay 

Full 

12,288 

16,800 

67,200 

1% 

VoIP 

Frame Relay 

Full 

15,360 

16,800 

67,200 

0% 

VoIP 

Frame Relay 

Full 

18,432 

16,800 

67,200 

0% 

VoIP 

Frame Relay 

Full 

43,008 

16,800 

67,200 

0 % 

VoIP over PPP link w/ RTP Header Compression 




VoIP 

PPP 

Full 

56 

18,400 

73,600 

131% <-!! 

VoIP 

PPP 

Full 

64 

18,400 

73,600 

115% <-!! 

VoIP 

PPP 

Full 

128 

18,400 

73,600 

58% 

VoIP 

PPP 

Full 

256 

18,400 

73,600 

29% 

VoIP 

PPP 

Full 

512 

18,400 

73,600 

14% 

VoIP 

PPP 

Full 

768 

18,400 

73,600 

10% 

VoIP 

PPP 

Full 

1,024 

18,400 

73,600 

7% 

VoIP 

PPP 

Full 

1,536 

18,400 

73,600 

5% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.729(w/VAD) Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* 

G.729 w/ 10ms Packetization w/ VAD 






Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

Voice directly in Frame Relay 






VoFR 

Frame Relay 

Full 

56 

15,200 

60,800 

109% <-!! 

VoFR 

Frame Relay 

Full 

64 

15,200 

60,800 

95% <-* 

VoFR 

Frame Relay 

Full 

128 

15,200 

60,800 

48% 

VoFR 

Frame Relay 

Full 

256 

15,200 

60,800 

24% 

VoFR 

Frame Relay 

Full 

512 

15,200 

60,800 

12% 

VoFR 

Frame Relay 

Full 

768 

15,200 

60,800 

8% 

VoFR 

Frame Relay 

Full 

1,024 

15,200 

60,800 

6% 

VoFR 

Frame Relay 

Full 

1,536 

15,200 

60,800 

4% 

VoFR 

Frame Relay 

Full 

3,072 

15,200 

60,800 

2% 

VoFR 

Frame Relay 

Full 

6,144 

15,200 

60,800 

1% 

VoFR 

Frame Relay 

Full 

9,216 

15,200 

60,800 

1% 

VoFR 

Frame Relay 

Full 

12,288 

15,200 

60,800 

0% 

VoFR 

Frame Relay 

Full 

15,360 

15,200 

60,800 

0% 

VoFR 

Frame Relay 

Full 

18,432 

15,200 

60,800 

0% 

VoFR 

Frame Relay 

Full 

43,008 

15,200 

60,800 

0% 
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Voiceover IP (VoIP) Bandwidth Demand Calculator 


G.729(w/VAD) Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* 

G.729 w/ 10ms Packetization w/ VAD 






Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

Voice directly in ATM/AAL-5 






VoATM 

ATM (AAL-5) 

Full 

1,536 

42,400 

169,600 

11% 

Vo ATM 

ATM (AAL-5) 

Full 

3,072 

42,400 

169,600 

6% 

VoATM 

ATM (AAL-5) 

Full 

6,144 

42,400 

169,600 

3% 

VoATM 

ATM (AAL-5) 

Full 

9,216 

42,400 

169,600 

2% 

VoATM 

ATM (AAL-5) 

Full 

12,288 

42,400 

169,600 

1% 

VoATM 

ATM (AAL-5) 

Full 

15,360 

42,400 

169,600 

1% 

VoATM 

ATM (AAL-5) 

Full 

18,432 

42,400 

169,600 

1% 

VoATM 

ATM (AAL-5) 

Full 

43,008 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

50,112 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

150,336 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

601,344 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

2,405,376 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

4,810,752 

42,400 

169,600 

0% 

VoATM 

ATM (AAL-5) 

Full 

9,621,504 

42,400 

169,600 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) <-* 

G.729 w/ 20ms Packetization w/ VAD G.729 w/ 30ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

62,400 

249,600 

2% 

46,933 

187,733 

2% 

62,400 

249,600 

0% 

46.933 

187,733 

0% 

31,200 

124,800 

0% 

23,467 

93,867 

0% 

26,400 

105,600 

189% <-!! 

20,267 

81,067 

145% <-!! 

26,400 

105,600 

165% <-!! 

20,267 

81,067 

127% <-!! 

26,400 

105,600 

83% <-* 

20,267 

81,067 

63% 

26,400 

105,600 

41% 

20,267 

81,067 

32% 

26,400 

105,600 

21% 

20,267 

81,067 

16% 

26,400 

105,600 

14% 

20,267 

81,067 

11% 

26,400 

105,600 

10% 

20,267 

81,067 

8% 

26,400 

105,600 

7% 

20,267 

81,067 

5% 

26,400 

105,600 

3% 

20,267 

81,067 

3% 

26,400 

105,600 

2% 

20,267 

81,067 

1% 

26,400 

105,600 

1% 

20,267 

81,067 

1% 

26,400 

105,600 

1% 

20,267 

81,067 

1% 

26,400 

105,600 

1% 

20,267 

81,067 

1% 

26,400 

105,600 

1% 

20,267 

81,067 

0% 

26,400 

105,600 

0% 

20,267 

81,067 

0% 

27,200 

108,800 

194% <-!! 

20,800 

83,200 

149% <-!! 

27,200 

108,800 

170% <-!! 

20,800 

83,200 

130% <-!! 

27,200 

108,800 

85% <-' 

20,800 

83,200 

65% 

27,200 

108,800 

43% 

20,800 

83,200 

33% 

27,200 

108,800 

21% 

20,800 

83,200 

16% 

27,200 

108,800 

14% 

20,800 

83,200 

11% 

27,200 

108,800 

11% 

20,800 

83,200 

8% 

27,200 

108,800 

7% 

20,800 

83,200 

5% 

42,400 

169,600 

11% 

28,267 

113,067 

7% 

42,400 

169,600 

6% 

28,267 

113,067 

4% 

42,400 

169,600 

3% 

28,267 

113,067 

2% 

42,400 

169,600 

2% 

28,267 

113,067 

1% 

42,400 

169,600 

1% 

28,267 

113,067 

1% 

42,400 

169,600 

1% 

28,267 

113,067 

1% 

42,400 

169,600 

1% 

28,267 

113,067 

1% 

42,400 

169,600 

0% 

28,267 

113,067 

0% 

42,400 

169,600 

0% 

28,267 

113,067 

0% 

42,400 

169,600 

0% 

28,267 

113,067 

0% 

42,400 

169,600 

0% 

28,267 

113,067 

0% 

42,400 

169,600 

0% 

28,267 

113,067 

0% 

42,400 

169,600 

0% 

28,267 

113,067 

0% 

42,400 

169,600 

0% 

28,267 

113,067 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-• Demand exceeds 70% (caution) <-’ 

G.729 w/ 20ms Packetization w/ VAD G.729 w/ 30ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

12,400 

49,600 

89% <-• 

10,933 

43,733 

78% <-' 

12,400 

49,600 

78% <-• 

10,933 

43,733 

68% 

12,400 

49,600 

39% 

10,933 

43,733 

34% 

12,400 

49,600 

19% 

10,933 

43,733 

17% 

12,400 

49,600 

10% 

10,933 

43,733 

9% 

12,400 

49,600 

6% 

10,933 

43,733 

6% 

12,400 

49,600 

5% 

10,933 

43,733 

4% 

12,400 

49,600 

3% 

10,933 

43,733 

3% 

12,400 

49,600 

2% 

10,933 

43,733 

1% 

12,400 

49,600 

1% 

10,933 

43,733 

1% 

12,400 

49,600 

1% 

10,933 

43,733 

0% 

12,400 

49,600 

0% 

10,933 

43,733 

0 % 

12,400 

49,600 

0% 

10,933 

43,733 

0% 

12,400 

49,600 

0% 

10,933 

43,733 

0% 

12,400 

49,600 

0% 

10,933 

43,733 

0% 

13,200 

52,800 

94% <-* 

11,467 

45,867 

82% <-' 

13,200 

52,800 

83% <-* 

11,467 

45,867 

72% <-' 

13,200 

52,800 

41% 

11,467 

45,867 

36% 

13,200 

52,800 

21% 

11,467 

45,867 

18% 

13,200 

52,800 

10% 

11,467 

45,867 

9% 

13,200 

52,800 

7% 

11,467 

45,867 

6% 

13,200 

52,800 

5% 

11,467 

45,867 

4% 

13,200 

52,800 

3% 

11,467 

45,867 

3% 



P 

P 

P 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) <-• 

G.729 w/ 20ms Packetization w/ VAD G.729 w/ 30ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

11,600 

46,400 

83% <-* 

10,400 

41,600 

74% 

11,600 

46,400 

73% <-’ 

10,400 

41,600 

65% 

11,600 

46,400 

36% 

10,400 

41,600 

33% 

11,600 

46,400 

18% 

10,400 

41,600 

16% 

11,600 

46,400 

9% 

10,400 

41,600 

8% 

11,600 

46,400 

6% 

10,400 

41,600 

5% 

11,600 

46,400 

5% 

10,400 

41,600 

4% 

11,600 

46,400 

3% 

10,400 

41,600 

3% 

11,600 

46,400 

2% 

10,400 

41,600 

1% 

11,600 

46,400 

1% 

10,400 

41,600 

1% 

11,600 

46,400 

1% 

10,400 

41,600 

0% 

11,600 

46,400 

0% 

10,400 

41,600 

0% 

11,600 

46,400 

0% 

10,400 

41,600 

0% 

11,600 

46,400 

0% 

10,400 

41,600 

0% 

11,600 

46,400 

0% 

10,400 

41,600 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


<-!! Demand exceeds 100%! (can't do it!) <-!! 
<-* Demand exceeds 70% (caution) <-" 


Demand exceeds 100%! (can't do it!) 
Demand exceeds 70% (caution) 


G.729 w/ 20ms Packetization w/ VAD 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

21,200 

84,800 

6% 

21,200 

84,800 

3% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 


G.729 w/ 30ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

14,133 

56,533 

4% 

14,133 

56,533 

2% 

14,133 

56,533 

1% 

14,133 

56,533 

1% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


By: Matthew F. Michels 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-• Demand exceeds 70% (caution) <-* 


G.729 w / 40ms Packetization w/ VAD 

G.729 w / 60ms Packetization w/ VAD 

Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

39,200 

156,800 

2% 

31,467 

125,867 

1% 

39,200 

156,800 

0% 

31,467 

125,867 

0% 

19,600 

78,400 

0% 

15,733 

62,933 

0% 

17,200 

68,800 

123% <-!! 

14,133 

56,533 

101% 

17,200 

68,800 

108% <-!! 

14,133 

56,533 

88% 

17,200 

68,800 

54% 

14,133 

56,533 

44% 

17,200 

68,800 

27% 

14,133 

56,533 

22% 

17,200 

68,800 

13% 

14,133 

56,533 

11% 

17,200 

68,800 

9% 

14,133 

56,533 

7% 

17,200 

68,800 

7% 

14,133 

56,533 

6% 

17,200 

68,800 

4% 

14,133 

56,533 

4% 

17,200 

68,800 

2% 

14,133 

56,533 

2% 

17,200 

68,800 

1% 

14,133 

56,533 

1% 

17,200 

68,800 

1% 

14,133 

56,533 

1% 

17,200 

68,800 

1% 

14,133 

56,533 

0% 

17,200 

68,800 

0% 

14,133 

56,533 

• 0% 

17,200 

68,800 

0% 

14,133 

56,533 

0% 

17,200 

68,800 

0% 

14,133 

56,533 

0% 

17,600 

70,400 

126% <-!! 

14,400 

57,600 

103% 

17,600 

70,400 

110% <-!! 

14,400 

57,600 

90% 

17,600 

70,400 

55% 

14,400 

57,600 

45% 

17,600 

70,400 

28% 

14,400 

57,600 

23% 

17,600 

70,400 

14% 

14,400 

57,600 

11% 

17,600 

70,400 

9% 

14,400 

57,600 

8% 

17,600 

70,400 

7% 

14,400 

57,600 

6% 

17,600 

70,400 

5% 

14,400 

57,600 

4% 

21,200 

84,800 

6% 

21,200 

84,800 

6% 

21,200 

84,800 

3% 

21,200 

84,800 

3% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

1% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 

21,200 

84,800 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) 


G.729 w/ 40ms Packetization w/ VAD 

G.729 w/ 60ms Packetization w/ VAD 

Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

10,200 

40,800 

73% <-' 

9,467 

37,867 

68% 

10,200 

40,800 

64% 

9,467 

37,867 

59% 

10,200 

40,800 

32% 

9,467 

37,867 

30% 

10,200 

40,800 

16% 

9,467 

37,867 

15% 

10,200 

40,800 

8% 

9,467 

37,867 

7% 

10,200 

40,800 

5% 

9,467 

37,867 

5% 

10,200 

40,800 

4% 

9,467 

37,867 

4% 

10,200 

40,800 

3% 

9,467 

37,867 

2% 

10,200 

40,800 

1% 

9,467 

37,867 

1% 

10,200 

40,800 

1% 

9,467 

37,867 

1% 

10,200 

40,800 

0% 

9,467 

37,867 

0% 

10,200 

40,800 

0% 

9,467 

37,867 

0% 

10,200 

40,800 

0% 

9,467 

37,867 

0% 

10,200 

40,800 

0% 

9,467 

37,867 

0% 

10,200 

40,800 

0% 

9,467 

37,867 

0% 

10,600 

42,400 

76% <-’ 

9,733 

38,933 

70% 

10,600 

42,400 

66% 

9,733 

38,933 

61% 

10,600 

42,400 

33% 

9,733 

38,933 

30% 

10,600 

42,400 

17% 

9,733 

38,933 

15% 

10,600 

42,400 

8% 

9,733 

38,933 

8% 

10,600 

42,400 

6% 

9,733 

38,933 

5% 

10,600 

42,400 

4% 

9,733 

38,933 

4% 

10,600 

42,400 

3% 

9,733 

38,933 

3% 


Ver. 2.1. 3/8/2001 


Matthew F. Michels 



Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-* Demand exceeds 70% (caution) <-* 

G.729 w/ 40ms Packetization w/ VAD G.729 w/ 60ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

9,800 

39,200 

70% <-* 

9,200 

36,800 

66% 

9,800 

39,200 

61% 

9,200 

36,800 

58% 

9,800 

39,200 

31% 

9,200 

36,800 

29% 

9,800 

39,200 

15% 

9,200 

36,800 

14% 

9,800 

39,200 

8% 

9,200 

36,800 

7% 

9,800 

39,200 

5% 

9,200 

36,800 

5% 

9,800 

39,200 

4% 

9,200 

36,800 

4% 

9,800 

39,200 

3% 

9,200 

36,800 

2% 

9,800 

39,200 

1% 

9,200 

36,800 

1% 

9,800 

39,200 

1% 

9,200 

36,800 

1% 

9,800 

39,200 

0% 

9,200 

36,800 

0% 

9,800 

39,200 

0% 

9,200 

36,800 

0% 

9,800 

39,200 

0% 

9,200 

36,800 

0 % 

9,800 

39,200 

0% 

9,200 

36,800 

0 % 

9,800 

39,200 

0% 

9,200 

36,800 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 
Demand exceeds 70% (caution) <-• Demand exceeds 70% (caution) <-* 


G.729 w/ 40ms Packetization w/ VAD 

G.729 w / 60ms Packetization w/ VAD 

Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

10,600 

42,400 

3% 

14,133 

56,533 

4% 

10,600 

42,400 

1% 

14,133 

56,533 

2% 

10,600 

42,400 

1% 

14,133 

56,533 

1% 

10,600 

42,400 

0% 

14,133 

56,533 

1% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 

10,600 

42,400 

0% 

14,133 

56,533 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.723 (w/ VAD) <-!! 

G.723 is only available in increments <-' 

of 30ms packetization 

G.723 w/ 10ms Packetization w/ VAD 






Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

VoIP over Ethernet LAN 






VoIP 

802.3 

Half 

10,000 

n/a 

n/a 

0% 

VoIP 

802.3 

Half 

100,000 

n/a 

n/a 

0% 

VoIP 

802.3 

Full 

100,000 

n/a 

n/a 

0% 

VoIP over Frame Relay w/o RTP Header Compression 




VoIP 

Frame Relay 

Full 

56 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

64 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

128 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

256 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

512 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

768 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

1,024 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

1,536 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

3,072 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

6,144 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

9,216 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

12,288 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

15,360 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

18,432 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

43,008 

n/a 

n/a 

0% 

VoIP over PPP link w/o RTP Header Compression 




VoIP 

PPP 

. Full 

56 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

64 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

128 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

256 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

512 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

768 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

1,024 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

1,536 

n/a 

n/a 

0% 

VoIP in ATM/AAL-5 






VoIP 

ATM (AAL-5) 

Full 

1,536 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

3,072 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

6,144 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

9,216 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

12,288 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

15,360 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

18,432 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

43,008 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

50,112 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

150,336 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

601,344 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

2,405,376 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

4,810,752 

n/a 

n/a 

0% 

VoIP 

ATM (AAL-5) 

Full 

9,621,504 

n/a 

n/a 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.723 (w/ VAD) <.n 

G.723 is only available in increments <-* 
of 30ms packetization 

G.723 w/ 10ms Packetization w/ VAD 






Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

VoIP over Frame Relay w/ RTP Header 

Compression 




VoIP 

Frame Relay 

Full 

56 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

64 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

128 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

256 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

512 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

768 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

1,024 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

1,536 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

3,072 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

6,144 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

9,216 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

12,288 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

15,360 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

18,432 

n/a 

n/a 

0% 

VoIP 

Frame Relay 

Full 

43,008 

n/a 

n/a 

0% 

VoIP over PPP link w/ RTP Header Compression 




VoIP 

PPP 

Full 

56 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

64 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

128 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

256 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

512 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

768 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

1,024 

n/a 

n/a 

0% 

VoIP 

PPP 

Full 

1,536 

n/a 

n/a 

0% 


P 

P 

: 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.723 (w/ VAD) <-!! 

G.723 is only available in increments <-* 

of 30ms packetization 

G.723 w/ 10ms Packetization w/ VAD 

Bandwidth Total Link 



over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 

Link Type 

Voice directly in Frame Relay 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

VoFR 

Frame Relay 

Full 

56 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

64 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

128 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

256 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

512 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

768 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

1.024 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

1,536 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

3,072 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

6,144 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

9,216 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

12,288 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

15,360 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

18,432 

n/a 

n/a 

0% 

VoFR 

Frame Relay 

Full 

43,008 

n/a 

n/a 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


G.723 (w/ VAD) <-!! 

G.723 is only available in increments <-* 
of 30ms packetization 

G.723 w/ 10ms Packetization w/ VAD 






Bandwidth 

Total 

Link 


over 

Full/Half 

Link Speed 

per trunk 

Bandwidth 

Utilization 


Link Type 

Duplex 

(kbps) 

(bps) 

(bps) 

(%) 

Voice directly in ATM/AAL-5 






VoATM 

ATM (AAL-5) 

Full 

1,536 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

3,072 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

6,144 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

9,216 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

12,288 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

15,360 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

18,432 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

43,008 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

50,112 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

150,336 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

601,344 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

2,405,376 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

4,810,752 

n/a 

n/a 

0% 

VoATM 

ATM (AAL-5) 

Full 

9,621,504 

n/a 

n/a 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


<-!! Demand exceeds 100%! (can't do it!) <-!! 


G.723 is only available in increments <-* 

of 30ms packetization 

G.723 w/ 20ms Packetization w/ VAD 

Demand exceeds 70% (caution) 

G.723 w/ 30ms Packetization w/ VAD 

Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

n/a 

n/a 

0% 

43,733 

174,933 

2% 

n/a 

n/a 

0% 

43,733 

174,933 

0% 

n/a 

n/a 

0% 

21,867 

87,467 

0% 

n/a 

n/a 

0% 

18,667 

74,667 

133% 

n/a 

n/a 

0% 

18,667 

74,667 

117% 

n/a 

n/a 

0% 

18,667 

74,667 

58% 

n/a 

n/a 

0% 

18,667 

74,667 

29% 

n/a 

n/a 

0% 

18,667 

74,667 

15% 

n/a 

n/a 

0% 

18,667 

74,667 

10% 

n/a 

n/a 

0% 

18,667 

74,667 

7% 

n/a 

n/a 

0% 

18,667 

74,667 

5% 

n/a 

n/a 

0% 

18,667 

74,667 

2% 

n/a 

n/a 

0% 

18,667 

74,667 

1% 

n/a 

n/a 

0% 

18,667 

74,667 

1% 

n/a 

n/a 

0% 

18,667 

74,667 

1% 

n/a 

n/a 

0% 

18,667 

74,667 

0% 

n/a 

n/a 

0% 

18,667 

74,667 

0% 

n/a 

n/a 

0% 

18,667 

74,667 

0% 

n/a 

n/a 

0% 

19,200 

76,800 

137% 

n/a 

n/a 

0% 

19,200 

76,800 

120% 

n/a 

n/a 

0% 

19,200 

76,800 

60% 

n/a 

n/a 

0% 

19,200 

76,800 

30% 

n/a 

n/a 

0% 

19,200 

76,800 

15% 

n/a 

n/a 

0% 

19,200 

76,800 

10% 

n/a 

n/a 

0% 

19,200 

76,800 

8% 

n/a 

n/a 

0% 

19,200 

76,800 

5% 

n/a 

n/a 

0% 

28,267 

113,067 

7% 

n/a 

n/a 

0% 

28,267 

113,067 

4% 

n/a 

n/a 

0% 

28,267 

113,067 

2% 

n/a 

n/a 

0% 

28,267 

113,067 

1% 

n/a 

n/a 

0% 

28,267 

113,067 

1% 

n/a 

n/a 

0% 

28,267 

113,067 

1% 

n/a 

n/a 

0% 

28,267 

113,067 

1% 

n/a 

n/a 

0% 

28,267 

113,067 

0% 

n/a 

n/a 

0% 

28,267 

113,067 

0% 

n/a 

n/a 

0% 

28,267 

113,067 

0% 

n/a 

n/a 

0% 

28,267 

113,067 

0% 

n/a 

n/a 

0% 

28,267 

113,067 

0% 

n/a 

n/a 

0% 

28,267 

113,067 

0% 

n/a 

n/a 

0% 

28,267 

113,067 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


<-!! Demand exceeds 100%! (can't do it!) <-!! 
G.723 is only available in increments <-* Demand exceeds 70% (caution) <-* 

of 30ms packetization 

G.723 w/ 20ms Packetization w/ VAD G.723 w/ 30ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

n/a 

n/a 

0% 

9,333 

37,333 

67% 

n/a 

n/a 

0% 

9,333 

37,333 

58% 

n/a 

n/a 

0% 

9,333 

37,333 

29% 

n/a 

n/a 

0% 

9,333 

37,333 

15% 

n/a 

n/a 

0% 

9,333 

37,333 

7% 

n/a 

n/a 

0% 

9,333 

37,333 

5% 

n/a 

n/a 

0% 

9,333 

37,333 

4% 

n/a 

n/a 

0% 

9,333 

37,333 

2% 

n/a 

n/a 

0% 

9,333 

37,333 

1% 

n/a 

n/a 

0% 

9,333 

37,333 

1% 

n/a 

n/a 

0% 

9,333 

37,333 

0% 

n/a 

n/a 

0 % 

9,333 

37,333 

0% 

n/a 

n/a 

0% 

9,333 

37,333 

0% 

n/a 

n/a 

0% 

9,333 

37,333 

0% 

n/a 

n/a 

0% 

9,333 

37,333 

0% 

n/a 

n/a 

0% 

9,867 

39,467 

70% <-' 

n/a 

n/a 

0% 

9,867 

39,467 

62% 

n/a 

n/a 

0% 

9,867 

39,467 

31% 

n/a 

n/a 

0% 

9,867 

39,467 

15% 

n/a 

n/a 

0% 

9,867 

39,467 

8% 

n/a 

n/a 

0% 

9,867 

39,467 

5% 

n/a 

n/a 

0% 

9,867 

39,467 

4% 

n/a 

n/a 

0% 

9,867 

39,467 

3% 


* 

9 

9 


By: Matthew F. Michels 


Ver. 2.1, 3/8/2001 


Page 69 of 75 



Voice over IP (VoIP) Bandwidth Demand Calculator 


<-!! Demand exceeds 100%! (can't do it!) <-!! 


G.723 is only available in increments <-* 

of 30ms packetization 

G.723 w/ 20ms Packetization w/ VAD 

Demand exceeds 70% (caution) 

G.723 w/ 30ms Packetization w/ VAD 

Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

n/a 

n/a 

0% 

8,800 

35,200 

63% 

n/a 

n/a 

0% 

8,800 

35,200 

55% 

n/a 

n/a 

0% 

8,800 

35,200 

28% 

n/a 

n/a 

0% 

8,800 

35,200 

14% 

n/a 

n/a 

0% 

8,800 

35,200 

7% 

n/a 

n/a 

0% 

8,800 

35,200 

5% 

n/a 

n/a 

0% 

8,800 

35,200 

3% 

n/a 

n/a 

0% 

8,800 

35,200 

2% 

n/a 

n/a 

0% 

8,800 

35,200 

1% 

n/a 

n/a 

0% 

8,800 

35,200 

1% 

n/a 

n/a 

0% 

8,800 

35,200 

0% 

n/a 

n/a 

0% 

8,800 

35,200 

0% 

n/a 

n/a 

0% 

8,800 

35,200 

0% 

n/a 

n/a 

0% 

8,800 

35,200 

0% 

n/a 

n/a 

0% 

8,800 

35,200 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


<-!! Demand exceeds 100%! (can't do it!) <-!! 


G.723 is only available in increments <-’ 

of 30ms packetization 

G.723 w/ 20ms Packetization w/ VAD 

Demand exceeds 70% (caution) 

G.723 w/ 30ms Packetization w/ VAD 

Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

n/a 

n/a 

0% 

14,133 

56,533 

4% 

n/a 

n/a 

0% 

14,133 

56,533 

2% 

n/a 

n/a 

0% 

14,133 

56,533 

1% 

n/a 

n/a 

0% 

14,133 

56,533 

1% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0 % 

n/a 

n/a 

0% 

14,133 

56,533 

0 % 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

p/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 

n/a 

n/a 

0% 

14,133 

56,533 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! 
Demand exceeds 70% (caution) <-* 

G.723 w/ 40ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0 % 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 


Demand exceeds 100%! (can't do it!) <-!! 
Demand exceeds 70% (caution) <-* 

G.723 w/ 60ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

28,267 

113,067 

1% 

28,267 

113,067 

0% 

14,133 

56,533 

0% 

12,533 

50,133 

90% <-' 

12,533 

50,133 

78% <-' 

12,533 

50,133 

39% 

12,533 

50,133 

20% 

12,533 

50,133 

10% 

12,533 

50,133 

7% 

12,533 

50,133 

5% 

12,533 

50,133 

3% 

12,533 

50,133 

2% 

12,533 

50,133 

1% 

12,533 

50,133 

1% 

12,533 

50,133 

0% 

12,533 

50,133 

0% 

12,533 

50,133 

0% 

12,533 

50,133 

0% 

12,800 

51,200 

91% <-' 

12,800 

51,200 

80% <- 

12,800 

51,200 

40% 

12,800 

51,200 

20% 

12,800 

51,200 

10% 

12,800 

51,200 

7% 

12,800 

51,200 

5% 

12,800 

51,200 

3% 

14,133 

56,533 

4% 

14,133 

56,533 

2% 

14,133 

56,533 

1% 

14,133 

56,533 

1% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-' Demand exceeds 70% (caution) <-* 


G.723 w / 40ms Packetization w/ VAD 

G.723 w/ 80ms Packetization w/ VAD 

Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

n/a 

n/a 

0% 

7,867 

31,467 

56% 

n/a 

n/a 

0% 

7,867 

31,467 

49% 

n/a 

n/a 

0% 

7,867 

31,467 

25% 

n/a 

n/a 

0% 

7,867 

31,467 

12% 

n/a 

n/a 

0% 

7,867 

31,467 

6% 

n/a 

n/a 

0% 

7,867 

31,467 

4% 

n/a 

n/a 

0% 

7,867 

31,467 

3% 

n/a 

n/a 

0% 

7,867 

31,467 

2% 

n/a 

n/a 

0% 

7,867 

31,467 

1% 

n/a 

n/a 

0% 

7,867 

31,467 

1% 

n/a 

n/a 

0% 

7,867 

31,467 

0% 

n/a 

n/a 

0% 

7,867 

31,467 

0% 

n/a 

n/a 

0% 

7,867 

31,467 

0% 

n/a 

n/a 

0% 

7,867 

31,467 

0% 

n/a 

n/a 

0% 

7,867 

31,467 

0% 

n/a 

n/a 

0% 

8,133 

32,533 

58% 

n/a 

n/a 

0% 

8,133 

32,533 

51% 

n/a 

n/a 

0% 

8,133 

32,533 

25% 

n/a 

n/a 

0% 

8,133 

32,533 

13% 

n/a 

n/a 

0% 

8,133 

32,533 

6% 

n/a 

n/a 

0% 

8,133 

32,533 

4% 

n/a 

n/a 

0% 

8,133 

32,533 

3% 

n/a 

n/a 

0% 

8,133 

32,533 

2% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


Demand exceeds 100%! (can't do it!) <-!! Demand exceeds 100%! (can't do it!) <-!! 

Demand exceeds 70% (caution) <-• Demand exceeds 70% (caution) <-’ 


G.723 w / 40ms Packetization w/ VAD 

G.723 w/ 60ms Packetization w/ VAD 

Bandwidth 

Total 

Link 

Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

(bps) 

(bps) 

(%) 

n/a 

n/a 

0% 

7,600 

30,400 

54% 

n/a 

n/a 

0% 

7,600 

30,400 

48% 

n/a 

n/a 

0% 

7,600 

30,400 

24% 

n/a 

n/a 

0% 

7,600 

30,400 

12% 

n/a 

n/a 

0% 

7,600 

30,400 

6% 

n/a 

n/a 

0% 

7,600 

30,400 

4% 

n/a 

n/a 

0% 

7,600 

30,400 

3% 

n/a 

n/a 

0% 

7.600 

30,400 

2% 

n/a 

n/a 

0% 

7,600 

30,400 

1% 

n/a 

n/a 

0% 

7,600 

30,400 

0% 

n/a 

n/a 

0% 

7,600 

30,400 

0% 

n/a 

n/a 

0% 

7,600 

30,400 

0% 

n/a 

n/a 

0% 

7,600 

30,400 

0% 

n/a 

n/a 

0% 

7,600 

30,400 

0% 

n/a 

n/a 

0% 

7,600 

30,400 

0% 
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Voice over IP (VoIP) Bandwidth Demand Calculator 


<-!! Demand exceeds 100%! (can't do it!) 
<-’ Demand exceeds 70% (caution) 


Demand exceeds 100%! (can't do it!) 
Demand exceeds 70% (caution) 

G.723 w/ 40ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 

n/a 

n/a 

0% 


G.723 w/ 60ms Packetization w/ VAD 


Bandwidth 

Total 

Link 

per trunk 

Bandwidth 

Utilization 

(bps) 

(bps) 

(%) 

14,133 

56,533 

4% 

14,133 

56,533 

2% 

14,133 

56,533 

1% 

14,133 

56,533 

1% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 

14,133 

56,533 

0% 
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Foreword 

Power Networks 

Power Networks are the next generation of Enterprise networks. Power Networks are 
not just another vendor's architecture, but rather a set of values and attributes delivered 
through Nortel's portfolio of enterprise network solutions and the products of our tech¬ 
nology partners. They consolidate a company's disparate communications and technol¬ 
ogy environments into an integrated multimedia network. 

Power Networks extend beyond the WAN to include a company's call centres, intranets 
and the Internet, on-site mobility, multimedia communications applications and telephony 
environments. With Power Networks, these applications, and the rest of the company's 
communications infrastructure, are integrated to enhance business performance. 

Drawing on expertise from five cornerstone technology areas; digital switching, wide 
area networking, mobility solutions, Internet and intranet solutions and multimedia 
applications, Nortel is uniquely positioned to deliver the next generation of high perfor¬ 
mance networks. 

Best in class 

Nortel is committed to providing best-in-class technology. The many industry firsts and 
business accolades stand as testimony to that commitment. 

Industry firsts include: 

- First VBR voice-over ATM on Passport 

- First frame relay SVC 

- First LAN Customer Premises Equipment (CPE) integration 

- First ATM/SONET integration 

- Distributed network architecture 

- Advanced frame/cell architecture 

- Comprehensive billing support system 

Nortel takes an active role in standards organisations such as the ITU-T and industry- 
focused groups such as the Frame Relay Forum and the ATM Forum. Nortel's leader¬ 
ship ensures that products anticipate new networking standards which are incorporated 
as key elements of design and functionality. 
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Business achievements include: 

- No. 1 in the Global FRAD Equipment market (Dataquest, ‘97) 

- No. 1 in the Global WAN Equipment market (Dataquest, '96) 

- No. 1 in the Global ATM Enterprise Switch Market (Yankee Group, ’96) 

- No. 1 in the Global Packet Switch Market (Dataquest, '96) 

- No. 1 in the Global ATM Access MUX Market (Dataquest, '96) 

- No. 2 in the Global ATM Core Switch Market (Yankee Group, '96) 

- No. 3 in the Global Frame Relay Equipment Market (Vertical Systems Group,'96) 

Voice communication 

Voice communication has long existed in the world of analogue and digital telephone 
exchanges. Fixed, dedicated, switched services have provided the user with the ability 
to place telephone calls to practically anywhere in the world. The way that voice is 
carried and switched within both public and private networks is set to change over the 
coming years with the evolution towards the Broadband-Integrated Services Digital 
Network (B-ISDN), as based upon Asynchronous Transfer Mode (ATM) technology. 

This evolution brings many benefits including more efficient use of network bandwidth 
and the ability to offer many different types of voice service. However, there are many 
issues, which first need to be understood and then overcome before these benefits can 
be realised. 

This booklet examines these issues. It highlights voice communication techniques in use 
today and investigates those that maybe commonplace in the future. Of course, with the 
limited space available we cannot hope to cover every technological aspect in depth. We 
trust that you will fmd this text a useful introduction to the main subject areas. And for 
those who are keen to leam more we have included many valuable references. 

References are given by a number in square brackets and listed in Appendix D e.g. [3]. 

Intended Audience 

This booklet is intended for a broad range of readers who are involved in the design, 
implementation, operation, management or support of enterprise wide voice networks. 
It has particular relevance to those with a background in data and/or limited experience 
in voice technologies, although it will also serve as a useful reference book for 
everybody involved in voice networks today. 
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Figure 3.2 Call Routing in a PBX Private Network 


3.3 Voice Interfaces on a PBX 

The types of voice interface available on PBXs are many and varied. They typically fall 
into three categories: 

Line Interfaces - These are the interfaces on the PBX that connect to the telephone on 
your desk. Line interfaces could include any of the types discussed in Sections 2.2 and 

2.3 and including: 

- 2 wire analogue loop disconnect/loop start 

- 2 or 4 wire analogue proprietary feature set 

- 4 wire digital set, either proprietary or conforming to Basic Rate ISDN standards 

Private Trunk Interfaces - These provide the links between PBXs within a multi-PBX 
private network. They allow calls to be routed from one PBX to another without the 
need to involve the public network so avoiding extra call cost. Private trunk interfaces 
typically include: 

- 2 or 4 wire analogue with E&M signalling 

- 4 wire analogue with AC 15 signalling 

- Digital trunk supporting CAS or CCS signalling 

Public Trunk Interfaces - These provide access from the PBX to the PSTN (Public 
Switched Telephone Network) for outgoing and/or incoming calls. Public trunk inter¬ 
faces typically include: 

- Ground Start analogue trunk: 2 wire, both-way calling 

- Analogue Direct Dial In (DDI): 2 wire, typically incoming calls only 

- Digital trunk supporting CAS or CCS signalling 
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4 Introduction to Digital Voice 

We have already discussed that many of today’s voice interfaces rely on analogue tech¬ 
nology. However, once into a PBX and into a wide area network, analogue voice is 
converted into a digital format in order to derive all the available benefits. This section 
looks at the background to digital voice followed by a more detailed look at how 
analogue speech is actually converted to a digital format. The integration of digital 
voice channels into primary rate digital interfaces is then examined and finally the need 
for synchronisation in a PBX network is examined. 

4.1 The Channel Bank 

The channel bank was one of the first devices to make use of digital voice in a practical 
environment. It is a device that takes multiple analogue voice channels, digitises them, 
and then multiplexes them onto a high speed digital link. Two main types of channel 
bank exist today, one supporting up to 24 voice channels and another supporting 30/31 
channels multiplexed onto 1.544Mbit/s and 2.048Mbit/s digital links respectively. 

The first channel bank was developed in North America in 1962 and was known as the 
D1 channel bank. It provided 24 analogue inputs each of which was converted to 8-bit 
PCM although the least significant bit was then ignored. The resulting seven bits were 
used for each voice sample and one bit was used for signalling, giving a combined data 
rate of 1.544Mbit/s. It was later found that this seven bit PCM gave unsatisfactory 
voice quality. Subsequent generations have used eight bit PCM with “robbed bit’ 
signalling (see Section 4.4.4). 

Channel banks have evolved beyond simply supporting analogue voice circuits. Today 
it is common for a channel bank to support many more interface types other than 
simply the analogue voice interface. For example: 

- 2 wire speech with loop disconnect signalling (incoming and outgoing) 

- 2/4 wire speech with E&M signalling 

- Data 0 - 64kbit/s 

- Data n x 64kbit/s 

- etc. 

4.2 Digital Voice - Pulse Code Modulation (PCM) - G.711 

Digital voice is a representation of analogue voice signals but using binary “I s and 
“0”s also known as bits. 

If we consider Figure 4.1, we can see the progress of a speech signal, from a talker’s 
mouth, via the telephone, into an analogue electrical signal and then into a digital form. 


Section 4 - Introduction to Digital Voice 
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Figure 4.1 Progress of speech signal Analogue to Digital 


When the talker speaks, they create variations of pressure in the air. The telephone 
picks up these pressure changes and turns them into an electrical signal that is 
analogous to the acoustic signal from the talker (hence the term analogue). This 
analogue signal is then converted into a digital stream of data bits which represents the 
digital voice signal. 

But why transport voice in a digital format? There are a number of reasons for this, a 
couple of key ones are as follows: 

Digital transmission is independent of distance - When an analogue signal is 
transmitted on a transmission channel it will be attenuated due to signal losses in the 
cable. In addition, noise will be picked up which will affect the quality of the voice. 
Therefore the signal that arrives at the destination is made up of a combination of the 
wanted signal and the noise. Amplifiers can be used to boost the signal back to the 
original level, however there is no easy way for the amplifier to distinguish between 
the wanted signal and the noise, therefore the noise will also be amplified. 

Digital signals take on one of two levels, represented by binary 0s and binary Is. 
While noise can be introduced onto the digital signal, it can easily be removed by 
regenerating equipment. Thus, the signal that arrives at the destination is an 
identical replica of the signal transmitted from the source. 

Multiplexing of voice and data - Since the digitised PCM voice is essentially a 
data stream running at a bit rate of 64kbit/s, it can readily be integrated with other 
PCM channels to make up an aggregate connection combining many voice channels 
in one physical connection. Being essentially data, it can also be combined with 
other ‘real’ data and transmitted over a common transmission medium. 

PCM is used for the digital representation of analogue voice signals in telephone 
systems and is defined in ITU-T Recommendation G.711 [3]. A simplified view of the 
process can be seen in Figure 4.2. 
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Sample analogue signal 
8000 times per second 


This results in a Pulse Amplitude 

Modulation (PAM) signal Quantise the PAM pulses 
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4.2 Analogue to PCM Conversion 


We begin with an analogue signal which is sampled at a rate of 8000 times per second. 
This rate is derived from a theory developed by a Harry Nyquist which says that the 
sampling rate must be at least twice the maximum frequency of the signal we are 
sampling (i.e. > 2 x 3.4kHz). This results in Pulse Amplitude Modulation (PAM) which 
is simply a series of pulses which represent the amplitude of the analogue signal at each 
sample time. Each PAM sample is then compared to a range of fixed quantisation 
levels, each of which is represented by a fixed binary pattern. The binary pattern of the 
closest quantisation level is then used to represent the PAM sample. 

Due to there being a finite number of quantisation levels available, this process intro¬ 
duces an error into the digital representation of the analogue signal. The more bits used 
in each sample results in more possible quantisation levels and less error. To achieve 
reasonable quality over the range of speech amplitudes found in networks requires a 
minimum of 12 bit PCM samples assuming linear quantisation (also known as uniform 
quantisation). A view of linear quantisation is given in Figure 4.3a. 


a) Linear/Uniform Quantisation Levels 



b) Non-linear/Non-uniform Quantisation Levels 



Figure 4.3 Linear/Uniform and Non-linear/Non-uniform Quantisation 
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In practice, this number of levels is unnecessary for two main reasons. Firstly average 
signal levels are normally small and only the lower quantisation levels actually get 
used. Secondly, the human ear operates in a logarithmic manner being more sensitive 
to distortion in low level signals than in high level signals. 

As a result, a technique known as companding is used which reduces the number of 
quantisation levels by retaining lots of levels at low signal amplitudes and reducing the 
number for high amplitudes. This process of companding is shown in Figure 4.3b. 

4.2.1 A-law and p- PCM 

There are two common types of PCM namely p-law and A-law each of which uses a 
different rule for the companding process. North America and Japan mostly use p-law, 
where as other area’s of the world require the use of A-law. Both types are defined in 
G.711 yet differ in a number of ways. Firstly the companding laws are different. The 
allocation of PCM codes differs in relation to the amplitude of the PAM samples. 
Secondly, with A-law, after converting from PAM to PCM, the even bits of each sample 
are inverted before being transmitted onto the digital transmission path. This bit 
inversion was originally used to ensure that a sufficient number of “l”s existed in the 
digital stream, because any channel that was idle would otherwise produce a pattern of 
only “0”s. In fact, on a 2.048Mbit/s PBX interface, this inversion is unnecessary, since 
the problem of too many “0”s is dealt with at the physical layer (see Section 4.3.1). 

For these reasons, when operating an international network where both p and A-law 
systems are used, it is important to perform a proper conversion between the two. The 
conversion process is given in G.711 which defines that digital paths between countries 
should carry signals encoded using the A-law. Where both countries use the same law, 
then that law should be used on digital paths between them. Any necessary conversion 
will be done in the countries using the p-law. 

4.2.2 Power of a Digital Signal 

It is easy to appreciate the power levels for an analogue interface since this is 
something that can be measured directly with a power meter. In the PCM world, there 
is no equivalent direct method. Instead a specific relationship is defined between an 
analogue signal and a digital sequence. The relationship of power to the digital signal 
is given in G.711 through two tables (one for p-law and one for A-law) that define a 
sequence of PCM samples which, when decoded, result in a sine- wave signal of 1kHz, 
at a nominal level of OdBmO. This gives a theoretical maximum level of +3.17dBmO 
for p-law +3.14dBmO for A-law. Any attempt to exceed these levels will result in 
distortion of the signal, simply because there are no more quantisation levels. 
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4.2.3 Distortion Resulting from the Digitisation Process 

When PCM values are allocated to the PAM samples, a certain amount of distortion 
results because of the finite number of quantisation levels available to quantise the 
analogue signal. 

4.3 The Digital 1.544Mbit/s PBX Interface (DS-1) 

The 1.544Mbit/s PBX interface is common to North America and Japan and is often 
referred to as a “Tl” or a “DS-l” interface. (In practice, these two terms are often used 
interchangeably, although this is wrong. DS-1 refers to a particular speed of 
1.544Mbit/s while Tl refers to a digital transmission system). It offers 23 or 24 traffic 
timeslots depending upon the type of signalling being used. 

In countries supporting DS-1 interfaces such as here in North America we offer various 
types of Tl transmission facility. AMI facilities simply expect the attached device (e.g. 
PBX) to provide an AMI electrical signal as described in Section 4.3.1. The main 
problem with this is that long strings of “0”s do not provide any electrical voltage tran¬ 
sitions. This can result in loss of repeater synchronisation on the transmission facility. 
It is therefore the responsibility of the attached equipment to ensure that sufficient “l”s 
exist to maintain synchronisation. The proportion of “l”s to “0”s is knows as the Is 
density. 

An alternative type of facility supports Bipolar Eight Zeroes Substitution (B8ZS) 
where violation pulses are introduced into the user data stream on the detection of an 
excess “0”s count. This technique is similar in principle to HDB3 as seen in 
Section 4.3.1 and is described below. 

4.3.1 Physical Interface 

The DS-1, unlike the El which is supported on both unbalanced coaxial cable and 
balanced twisted pair cables, is supported via twisted pair cable only. The DS-1 uses 
Alternate Mark Inversion (AMI) line coding to electrically encode the signal on the 
line. However, to overcome any problem of low Is density, a process called B8ZS is 
normally used instead of El’s HDB3. The operation of B8ZS is shown in Figure 4.4. It 

works by replacing strings of eight consecutive binary zeroes with a code that intro¬ 
duces bipolar violations into the 4th and 7th bit positions. The effect of this is to ensure 
that a sufficient number of voltage transitions exists while retaining the DC balanced 
nature of the signal. 
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Data pattern: 001 00001 100001 1 0 00010000 


Alternate Mark Inversion (AMI): 




AMI with HDB3 encoding: 





B = Inserted pulse conforming to AMI 
V = Inserted pulse violating AMI rule (violation) 


Figure 4.4 HDB3 Coding 


4.3.2 Framing - D4 

There are two common types of framing used on a DS-1 interface, D4 and Extended 
Superframe (ESF). 

D4 framing is shown in Figure 4.8. This consists of a frame of 193 bits with a repeti¬ 
tion rate of 8000 frames per second, giving a data rate of 1.544Mbit/s and a 125(is 
frame duration. Each frame contains 24 eight bit timeslots named timeslot 1 through to 
timeslot 24, and a single bit called the F or framing bit. All 24 timeslots are normally 
available for traffic except for when Common Channel Signalling is carried. In this 
case, timeslot 24 is reserved for the signalling channel. 

Framing is achieved using the F bit over a sequence of 12 frames also called a super¬ 
frame. In odd numbered frames the F bit is called Ft for terminal framing and performs 
frame alignment. In even numbered frames the F bit is called Fs and performs super¬ 
frame alignment. 

4.3.3 Framing - Extended Superframe (ESF) 

Today, ESF is more common than D4 due to its capabilities for monitoring the perfor¬ 
mance of an in service T1 link. This was not easily possible with D4 since the link 
would need to be taken out of service in order for performance testing to be carried out. 

The extended superframe, as shown in Figure 4.9, does exactly what its name implies 
and extends the 12 frame superframe to 24 frames. The use of the F bit is also changed. 
Only 6 out of the 24 in the ESF are now used for synchronisation purposes. Of the 
remaining 18 F bits, six are utilised for CRC checking to verify the integrity of the ESF, 
and 12 make up a Facility Data Link (FDL). The FDL is also known as the Data Link 
(DL) and is sometimes called the Embedded Operation Channel (EOC). The FDL is 
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available for the communication of alarms, loop backs and general performance infor¬ 
mation between terminating devices such as Customer Service Units (CSUs) which 
terminate the Tls at the customer premises. 



Figure 4.5 G. 704 Frame Structure for 2.048Mbit/s El 

4.3.4 Channel Associated Signalling (CAS) on DS-1 

The technique for CAS on a DS-1 is shown in Figures 4.8 and 4.9. The basic process 
is the same for both D4 and ESF framing. However for D4, only two signalling bits: A 
and B are used for each traffic timeslot. With ESF, four bits are used: A, B, C and D. 

The process used is called bit robbing because the least significant bit of each traffic 
timeslot in every sixth frame, is robbed away and used to carry signalling information 
rather than traffic. Meanwhile the other seven bits are left alone and continue to carry 
traffic such as PCM. Any distortion introduced to PCM voice traffic by this bit robbing 
technique is negligible and can be ignored. For data however the distortion can be 
significant. This is why data support is typically only 56kbit/s rather than 64kbit/s, with 
only the seven most significant bits being used. 

4.3.5 Common Channel Signalling on DS-1 

Common Channel Signalling utilises timeslot 24 to carry signalling information as 
HDLC based data messages. 
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4.3.6 DS-1 Alarms 

The DS-1 provides the same alarm conditions, albeit in a different manner and with a 
different naming convention. Figure 4.10 gives a comparison between the DS-1 and E- 
1 alarm conditions and the naming conventions. 

The method used on a DS-1 to provide a remote alarm indication differs depending on 
whether D4 or ESF framing is being used. 

With D4 trunks, a remote alarm indication, also called a yellow alarm, is given by 
transmitting a “0” in the bit 2 position of every timeslot. Putting this alarm indication 
in the traffic timeslots has two implications. Firstly, it destroys any valid information 
carried in the traffic timeslots. Secondly the receiver must validate the indication for a 
period of time (typically about 600ms) before taking any action, since it is possible that 
normal traffic could briefly mimic it. 

With ESF trunks, a remote alarm indication (yellow alann) is given by using the F bit 
Facility Data Link to transmit an alternating pattern of eight “0”s followed by eight 
“l”s then eight “0”s and so on. 

4.4 The Digital 2.048Mbit/s PBX Interface (El) 

A digital PBX interface running at 2.048Mbit/s and sometimes called the “El” 
interface is designed to conform to ITU-T Recommendation G.732 “Characteristics of 
Primary PCM Multiplex Equipment Operating at 2.048Mbit/s” [4]. This in turn refers 
to the following recommendations 

- G.703 : “Physical/Electrical Characteristics of Hierarchical Digital Interfaces” 

- G.704 : “Synchronous Frame Structures Used at Primary and Secondary 

Hierarchical Levels” 

- G.711 : “Pulse Code Modulation (PCM) of Voice Frequencies” 

4.4.1 Physical Interface - G.703 

ITU-T Recommendation G.703 [5] defines the electrical characteristics for many types 
and speed of interface including 64kbit/s, 1.544Mbit/s, 6.312Mbit/s, 32.064Mbit/s, 
44.736Mbit/s, 2.048Mbit/s, 8.448Mbit/s, 34.368Mbit/s, 139.264Mbit/s, 97.728Mbit/s 
and 155.52Mbit/s. For European voice applications they are concerned with the 
2.048Mbit/s interface. 

One of two types of physical interface may be used: the 75 ohms unbalanced coaxial 
interface, or the 120 ohms balanced twisted pair interface. Such parameters as voltage, 
voltage and frequency tolerance, amongst others are given in G.703. 
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PBX 1 



Transmission 

Network 


PBX 2 



Figure 4.6 El Alarms 

The actual data bits are transmitted using Alternate Mark Inversion (AMI) with High 
Density Bipolar 3 (HDB3) encoding. The objective of using these is twofold, firstly to 
remove any DC component from the transmitted signal (AMI does this), and secondly, 
to ensure that there is a sufficient number of voltage transitions in the signal. This is 
referred to as “Is density”, and is important so that the receiving device can derive 
synchronisation, or timing from the signal (HDB3 does this). 

Figure 4.7 shows AMI and HDB3 encoding. AMI employs a three level signal where 
binary zeroes are encoded using 0 Volts, and successive binary 1 s (marks) are encoded 
using alternating voltages of n2.37V for the unbalanced interface and n3V for the 
balanced interface. 

HDB3 is defined in G.703 and works by replacing each block of 4 successive zeroes by 
a pattern of either 000V or BOOV, where B represents an inserted pulse that conforms to 
the AMI rule and V represents an AMI violation. A violation is where two successive 
ones use the same electrical polarity. The choice of which pattern is used ensures that 
the number of B pulses between consecutive V pulses is odd, thus retaining the DC 
balanced nature of the signal which is important to help ensure error-free transmission. 

4.4.2 Framing Structure - G.704 

ITU-T Recommendation G.704 [6] defines the frame structures for a number of 
different speed links including 1.544Mbit/s, 6.312Mbit/s, 2.048Mbit/s and 
8.448Mbit/s. Again, as with the section on G.703 they are only interested in the 
2.048Mbit/s interface as shown in Figure 4.5. 

A frame of 256 bits is defined with a repetition rate of 8000 frames per second, giving 
a data rate of 2.048Mbit/s and a 125ps frame duration. Each frame comprises 32 eight 
bit timeslots named timeslot 0 through to timeslot 31. Timeslot 0 is used for a number 
of purposes including frame synchronisation and alarm reporting, while timeslot 16 is 
normally used to carry signalling information, although in some circumstances may be 
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Data pattern: 00 1 000000001 000000000 1 00 

Alternate Mark 
Inversion (AMI): 

V B B V 

AMI with B8ZS coding: 

B V V B 

B = Inserted pulse conforming to AMI 
V = Inserted pulse violating AMI rule (violation) 

Figure 4.7 Bipolar Eight Zeroes Substitution (B8ZS) Coding 

used to carry a traffic channel. Timeslots 1 to 15 and 17 to 31 are used to carry 30 traffic 
channels, normally PCM in the case of PBXs, although since they simply represent a 
64kbit/s channel, may be used to carry any form of traffic including data. 

As shown in Figure 4.5, alternate timeslot 0s carry different information. We are mostly 
concerned with the frame alignment signal 0011011 in even frames and the A (alarm) 
bit in odd frames. The purpose of the frame alignment signal is to allow the devices at 
each end of a link to synchronise to the frame, i.e. for them to know where the frame 
starts and which bits refer to which timeslot. The A-bit, also known as the Remote 
Alarm Indication (RAJ) is set to 0 in normal operation. In the event of a fault condition 
the A-bit will be set to a binary ‘ 1 
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The other bits. Si and Sa4-Sa8 are of less significance to us, although still important. 
Si is reserved for international use. One specific use, as given in G.704, is to carry a 
Cyclic Redundancy Check which can be used for enhanced error monitoring on the 
link. It is important to note that both ends of a link must be conFigured in the same way, 
either with CRC enabled or CRC disabled. 

Sa4 to Sa8 are additional spare bits which can be used for a number of purposes as 
defined in G.704. For example, Sa4 can be used as a message based link for operations, 
maintenance and performance monitoring. 

4.4.3 Channel Associated Signalling (CAS) on El 

Figure 4.5 demonstrates a form of signalling known as Channel Associated Signalling 
(CAS). With CAS, specific bits of data within the frame are defined to carry signalling 
information for each of the traffic timeslots. The information for each timeslot is trans¬ 
mitted as a group of four bits, designated A, B, C and D. Since timeslot 16 only has eight 
bits available to support 30 traffic timeslots, a multiframe structure of 16 frames (desig¬ 
nated frame 0 to frame 15) is defined to allow A, B, C and D bits to be carried for all 30 
timeslots. Frame 0 carries a Multiframe Alignment Signal (MFAS) of 4 zeroes. This 
allows the receiving system to identify which frame is which and so associate a traffic 
timeslot with its correct signalling bits. Frame 0 also carries a remote alarm indicator to 
signify loss of multiffame alignment. Timeslot 16 of frame 1 then carries A, B, C, and 
D bits for timeslots 1 and 17, timeslot 16 of frame 2 carries A, B, C, and D bits for 
timeslots 2 and 18, and so on up to frame 15 of the multiframe which carries A, B, C, 
and D bits for timeslots 15 and 31, after which the sequence repeats. 


p-p-D-D-D.D-D-D-.D-D.D-D- 

' CRC- .CRC- -!-CRC- .i- - CRC- -■.- CRC- -!-- crc- - - 

III III III III III III 

1 1 • 0- •---0-1-•*---1-'-•-•-0- 1 --*- 1 -1- - ---»-1- 

i , i..Li i i .1 i n i g a i m t i a M n l 

Extended Superframe = 24 frames 


- Data Link 

- - CRC 

- - Frame/Extended 

_ Superframe Alignmei 



Frame =193 bits 


n i i i i i ta 


MSB 


t_ 


LSB = Signalling bit 
Frame 6 - A bit 
Frame 12 - B bit 
Frame 18 - C bit 
Frame 24 - D bit 


Figure 4.9 ESF Framing 
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A common problem to watch out for is where the A, B, C, and D bits in timeslot 16 
associated with any of the traffic channels 1 to 15 are set to 0000. If this is the case then 
a false multiframe alignment signal will result, causing the whole signalling 
mechanism to fail. This situation is most common in a configuration where the PBX is 
connected to a multiplexer network which provides an idle pattern of 0000 to the PBX 
for channels that are not routed. In fact ITU-T G.704 recommends against the use of 
0000 for any signalling purposes for timeslots 1 to 15. It also recommends that if B, C 
and D are not used, then they should be set to B=l, C=0 and D=l. 

4.4.4 Common Channel Signalling (CCS) on El 

Common Channel Signalling utilises timeslot 16, as does CAS. However, rather than 
defining specific bits to carry signalling information for each of the traffic timeslots, 
signalling information is sent as High Level Data Link Control (HDLC) based data 
messages. 


El Interface 

DS-1 Interface 

Local Alarm e.g. Loss of Frame Alignment 
Remote Alarm Indication (RAI) 

Alarm Indication Signal (AIS) 

Red Alarm 

Yellow Alarm 

Blue Alarm 


Figure 4.10 DS-1 and El Alarm Comparison 


4.4.5 El Alarms 

Recommendation G.732 describes various fault conditions and subsequent actions that 
should be taken. It includes such conditions as power supply failure and codec failure, 
although here we shall only describe problems associated with the link itself. 

Frame Level Alarms - (With reference to Figure 4.6) In the event of one of the 
following problems occurring on the received signal (Rx), bit 3 in timeslot zero of odd 
numbered frames should be set to a 1 on the transmit (Tx) signal of that PBX. 

- Loss of incoming signal 

- Loss of frame alignment 

- Excessive error ratio 0 1 x 1(F 3 

Loss of frame alignment will occur for a number of reasons, including cabling or 
equipment faults. In the event of a failure in the transmission system between the two 
PBXs, the transmission system should automatically apply an Alarm Indication Signal 
(AIS) condition to the line of a continuous stream of Is. 
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Multiframe Alarm - When running Channel Associated Signalling, bit 6 of timeslot 
16 in frame 0 of the multiffame is used to indicate loss of multiframe alignment. If 
multiframe alignment is lost on the receive signal, the PBX will set bit 6 in its transmit 
signal as to the far end. 

Loss of multiframe alignment is a rare situation, since in a normal failure condition loss 
of frame alignment is more likely. A common cause of such a condition is mis-config- 
uration of one end of the link, as described in Section 4.3.3 above. 

4.5 The Need for PBX Synchronisation 

Digital PBXs, like many digital systems, operate internally in what is called a synchro¬ 
nous manner i.e. data is moved from one place to another using a common clock, or 
timing source. 

When two PBXs are connected together via a digital link, they must be synchronised 
in order to avoid bit slips and loss of frame synchronisation. 

Digital PBX interfaces typically have some form of buffering mechanism in order to 
overcome problems associated with jitter, wander and slight timing inaccuracies. 
However, in the event that the timing mismatch between two PBXs is too great, the 
buffer will fill. Once full, all that can be done is to empty it thus resulting in loss of data 
and loss of frame synchronisation. Frame synchronisation should be regained rapidly, 
so long as the timing mismatch is not too great. 

To understand why we need synchronisation, consider the following two examples. The 
first example shows two PBXs connected together with no synchronisation, while the 
second has PBX 2 synchronised to PBX 1. 


PBX 1 PBX 2 



Figure 4.11 Lack of Synchronisation 
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4.5.1 PBXs With No Synchronisation 

(With reference to Figure 4.11) The two PBXs are connected via a 1.544 Mbit/s link. 
This is only a nominal speed and some deviation is inevitable. It is quite possible that 
the transmit clock from PBX 1 is running slightly fast, say 1.544001 Mbit/s. This repre¬ 
sents an accuracy of about 5 parts in 10 million which is not uncommon. PBX 2, on the 
other hand is running slightly slow, say 1.543999 Mbit/s, again an accuracy of about 5 
parts in 10 million. 

Every second, PBX 1 transmits 1,544,001 bits of data onto the trunk, and PBX 2 
receives 1,543,999 bits, leaving two bits to be absorbed in a buffer at the input to 


PBX 1 PBX 2 



PBX 2. This will continue, two bits being absorbed in the buffer every second, until the 
buffer is full at which point it will be emptied causing loss of frame synchronisation. 
The effect of this is hard to predict but will probably cause clicks on any voice call 
currently in progress across the trunk or the disconnection of the calls completely. 

4.5.2 PBXs With Synchronisation 

(With reference to Figure 4.12) The system has been rearranged to allow PBX 2 to 
synchronise its internal clock to the data arriving at the digital trunk port. Now PBX 1 
still transmits data a bit fast at 1.544001 Mbit/s but now PBX 2 also receives data at 
1.544001 Mbit/s. The buffer does not fill, and frame synchronisation is never lost. 

This is all well and good in a point to point situation, but synchronisation also needs to 
be maintained in a full network scenario such as shown in Figure 4.13. 

There are a number of rules to follow with synchronisation, one of which is that the 
whole network should be synchronised back to the same clock source. Figure 4.13 
shows a small network of five PBXs with PBX 1 taking a high accuracy clock from an 
ISDN connection to the public network. An ideal clocking arrangement based upon this 
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network would be for PBX 2 to synchronise its system clock to the data on Link 1 
coming from PBX 1. PBX 3 would then synchronise to the data coming from PBX 2 
via Link 2. PBX 4 would synchronise to PBX 1 via Link 3 and PBX 5 to PBX 4 via 
Link 6. In this way, all PBXs are synchronised together. 

However, this scenario alone would not cater for a failure, for example if link 6 were 
to fail. In this case, PBX 5 would lose the clock to which it is synchronised. To 
overcome this problem, it is normal to have what is called a clock fallback list in each 
PBX and, in the event of a problem, the PBX will search for another valid source. 

However, one key criteria to follow with the clock fallback lists is to ensure that the 
network cannot get into a clocking loop. This is where, for example, PBX 4 takes its 
clock from PBX 3, PBX 3 from PBX 5 and PBX 5 from PBX 4. If this were to happen, 
then it is likely that errors will occur, causing loss of synchronisation on the links, 
possibly even to an extent where synchronisation cannot be regained, giving complete 
loss of one or more trunks. It is therefore very important to follow the manufacturers 
guidelines when configuring the network clocking. 


PBX 2 



Figure 4.13 Synchronisation in a Network of PBXs 
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5 Speech Compression 

The term speech compression, also referred to as voice compression, is normally used 
to describe the act of taking speech and digitising it at a bit rate of less than 64kbit/s. It 
is normal, however, to start with PCM at 64kbit/s and compress this to a lower rate. 
Ideally the resulting speech quality will not be alfected, however in practice, there will 
be some degradation which may or may not be apparent to the users. There are many 
different techniques used for speech compression which result in bit rates from a few 
kbit/s up to 40kbit/s. Each technique has different characteristics. 

PCM speech can be compressed because a large portion of the 64kbit/s bit stream is 
redundant. Furthermore it is thought that reasonable quality speech can be provided at 
rates as low as 1 kbit/s. The reasons that this has not yet been achieved, is that our under¬ 
standing of the way speech works is less than complete. As time goes by, new and more 
efficient techniques are being developed to drive the bit rate lower and lower while 
maintaining acceptable quality. 

This section looks at a number of speech compression techniques commonly in use 
today and other new systems that are starting to be used in the marketplace. We 
conclude with a section on speech compression impairments i.e. the negative effects 
that are introduced into speech conversations when using speech compression. 

5.1 Different Coding Types 

Speech compression schemes can be classified into one of three categories: Waveform 
Coding, Source Coding, and Hybrid Coding. 

Waveform Coding - Waveform coders attempt to reconstruct a waveform, in a form as 
close to the original signal as possible, based upon samples of the original waveform. 
In theory, this means that they are signal independent and should work with non-voice 
signals such as modem and fax traffic. Typically waveform coders are relatively simple 
to implement and produce acceptable quality speech at rates above 16kbit/s. Below this, 
the reconstructed speech quality degrades rapidly. 

PCM is an example of a waveform coding technique. If linear quantisation is used then at 
least 12 bits per PCM sample are needed to reproduce good quality speech. This results in 
a bit rate of 96kbit/s (8000 samples per second x 12). However, the nature of speech and 
that of human hearing is known not to follow a linear pattern. Much of a speech signal is 
of low level and our ears are sensitive not to the absolute amplitude of sounds, but instead 
to the log of the waveform amplitude. Therefore, in representing speech digitally, more bits 
are allocated at the lower levels than to the higher levels. This process, called companding, 
results in digitised speech of 64kbit/s. Therefore, even PCM effectively represents a 
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compressed digital speech form. Companding, was discussed in more detail in Section 4.2. 

Other common waveform coding techniques include Adaptive Differential Pulse Code 
Modulation (ADPCM) and Continuously Variable Slope Delta (CVSD). 

Source Coding - Source coders (also known as Vocoders) are more complex than 
waveform coders but can compress speech to bit rates of 2.4kbit/s and below. To 
achieve these compression rates, knowledge of the speech generation process is 
required. In principle, the speech signal is analysed and a model of the source is 
generated. A number of parameters are then transmitted to the destination to allow it to 
rebuild the model and thus recreate the speech. These parameters include such infor¬ 
mation as whether a sound is voiced (such as vowels) or unvoiced (such as most conso¬ 
nants), amplitude information and pitch. While source coders provide very low bit 
rates, the subjective quality of the regenerated speech can be poor. Often, although the 
speech is understood, recognition of who is speaking, referred to as talker recognition, 
is very poor. Furthermore, source coders do not carry non-speech signals, such as those 
from modems or facsimiles, very well. 

Because of these factors, source coders are not typically used in commercial applica¬ 
tions. Their main use has been in military applications where natural sounding speech 
is not as important as a very low bit rate which can then be encrypted for security 
purposes. 

Hybrid Coding - As the name suggests, hybrid coding uses aspects of both waveform 
and source coding, bringing together the benefits of the good quality speech of 
waveform coders and the low bit rates of source coders. 

Hybrid coders operate in a similar manner to source coders, in that a model is built of 
the parameters of the speech signal. But rather than transmit these parameters directly 
to the destination, they are used to synthesise a number of new signals. These are then 
compared with the original signal to fmd the best match. The modelled parameters, 
along with what is known as the excitation signal (representing how the synthesised 
signal was produced), are then transmitted to the destination where the speech is repro¬ 
duced. Examples of hybrid coders include Code Excited Linear Prediction (CELP) and 
its derivatives, some of which are described later in this Section. 

5.2 Adaptive Differential Pulse Code Modulation (ADPCM) 

ADPCM is the most common type of speech compression technique in use today. It 
offers good quality speech at a range of bit rates from 16kbit/s through to 40kbit/s. Its 
performance is well understood, and while non-standard versions exist, it has been 
“standardised” in a number of ITU-T Recommendations. These include ITU-T G.721 
which covers ADPCM at 32kbit/s, and G.723 which covers ADPCM at 16, 24 and 
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40kbit/s. Today, G.721 and G.723 have been combined and replaced by G.726 which 
covers all of the bit rates: 16, 24, 32 and 40kbit/s. 

32kbit/s ADPCM gives a speech quality which is practically indistinguishable from 
64kbit/s PCM. The quality does however degrade for 24kbit/s and 16kbit/s. 40kbit/s 
was implemented to cope with speech-band data such as modems and facsimiles, even 
so, it will only support modem speeds of up to about 12 to 14.4kbit/s. This means for 
example, that if a V.34 modem (normally 28.8kbit/s) was used across a 40kbit/s 
ADPCM link, the modem would downspeed to about 12 to 14.4kbit/s. 

ADPCM imposes an extremely low delay, with less than 1ms encode and decode times. 
This, along with its reasonable quality (at least at the higher bit rates) has made it 
particularly attractive for carrying speech across enterprise networks and it is still the 
most popular compression algorithm in use today. 

ADPCM coders are waveform coders which, instead of quantising the speech signal 
directly, quantise the difference between the speech signal and a prediction of what the 
speech signal will be. It achieves this by using the fact that adjacent samples are usually 
similar to each other. The value of a sample can be predicted with some accuracy by 
considering the values of preceding samples. For example, the simplest prediction is 
that the next sample will be the same as the current one. In this case, we produce what 
is called Differential Pulse Code Modulation (DPCM) which is the basis of ADPCM. 




Figure 5.1 Differential Pulse Code Modulation (DPCM) 


Figure 5.1 shows DPCM in action, where simply the difference between one sample 
and the next is transmitted from the source to the destination. 

For PCM the analogue speech signal is sampled at regular points and the absolute level 
of the sample is encoded. With DPCM, the difference between one sample and the next 
is encoded. By doing this, fewer bits are needed to encode the signal. Although in 
practice speech samples don’t change rapidly, when they do the changes in signal level 
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Difference can be encoded 



Figure 5.2 Adaptive Differential Pulse Code Modulation (ADPCM) 


are often greater than can be encoded using DPCM. This results in distortion of the 
signal as shown in Figure 5.1. 

With ADPCM, however, the amplitude range over which a given number of bits are 
used to encode a sample varies, or adapts, depending upon the range of amplitudes 
occurring at the time. This can be seen in Figure 5.2 which shows the principle of 
encoding the difference between the actual signal and a prediction of what it will be, 
based on the prediction that the next sample will be the same as the current one. 

The general rule that is used by ADPCM is as follows: 

“When signals are quantised towards the limit of the current range, the 
range used to quantise the next sample is changed”. 

During the first few samples, the difference between one and the next will be relative¬ 
ly small. These differences are encoded using the full range of quantisation levels that 
are available given the number of bits available for each sample. For example, at 
32kbit/s, the difference is encoded in four bits, one for the sign (i.e whether the next 
sample is more positive or negative than that predicted) and three for the magnitude 
of the difference. A few samples further on, the difference between one and the next is 
greater, yet can still be encoded using the full range of quantisation levels. This is 
achieved through the process of adaptation, where the 
amplitude range that can be encoded with the four bits 
changes depending upon the amplitudes at the time. 

As previously mentioned, ADPCM supports four 
different bit rates. The different rates are achieved 
through the number of bits used to encode the difference 

between one sample and the next as seen in Figure 5.3. . „ . 

1 6 Figure 5.3 ADPCM bits 


Rate 

No. bits 

40kbit/s 

5 

32kbit/s 

4 

24kbit/s 

3 

16kbit/s 

2 
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5.3 Code Excited Linear Prediction (CELP) 

At bit rates of around 16kbit/s and below, the quality of waveform coders falls rapidly. 
We have also seen that source coders, while operating at very low bit rates, tend to 
reduce the talker recognition substantially. Therefore, hybrid schemes, especially CELP 
coders and their derivatives tend to be used today for sub 16kbit/s compression. Many 
CELP implementations are proprietary to the manufacturer although we shall also 
discuss two standardised versions known as LD-CELP as defined in ITU-T G.728 and 
CS-ACELP as defined in ITU-T G.729. 

The essence of a CELP encoder is to analyse the incoming speech and transmit a number 
of parameters to the decoder so that the original speech can be reproduced as accurately 
as possible. These parameters include the mathematical model of a filter which simulates 
the talker’s vocal tract (i.e. what makes a person sound unique), gain information giving 
the level of the speech and a codebook index. The codebook index is used to point to a 
sequence of pre-defined speech samples, known as vectors, which is common to both the 
transmitter and the receiver. The number of codebook entries and the number of samples 
within each entry is dependent upon the actual CELP implementation. 

At the transmitter, groups of PCM speech samples (vectors) from the input speech, 
typically up to 20ms in length, are compared to the vectors stored in the codebook. This 
is done by generating a synthetic speech signal for every entry in the codebook and 
comparing it to the actual speech input vector. The index for the vector that produces 
the best match with the input speech waveform is then transmitted to the receiver. At 
the receiver, this waveform is then extracted from the codebook and filtered using the 
mathematical model of the original talker's vocal tract. This produces highly recognis¬ 
able and good quality speech. 

Due to the complexities of speech and the wide range of different human voices, the 
processing required for CELP is very intensive, typically of the order of 15 Million 
Instructions per Second (MIPS), or more, for one voice channel. This aside, today 
CELP is a very popular form of speech compression because of its high speech quality 
and low bit rates, typically between 4.8kbit/s and 16kbit/s. The main practical 
drawbacks of CELP come in two areas. First, CELP often produces end-to-end delays 
in the order of 50-100ms. This is due to a combination of the processing overhead and 
the number of speech samples that are buffered for analysis. Such high delays can cause 
problems (See Section 6 on echo). Second, since CELP is so tuned to human speech, it 
does not support voice band data well and can cause problems with modems and 
facsimiles as well as with the passing of any inband tones such as DTMF tones. 
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5.4 Low Delay Code Excited Linear Prediction (LD-CELP) - ITU-T G.728 

LD-CELP is based upon CELP and provides speech of a similar quality to 32kbit/s 
ADPCM, yet at a rate of 16kbit/s. It also incurs smaller delays, typically less than 2ms 
as compared to normal CELP with delays of 50-100ms. LD-CELP uses what is called 
backward adaption to produce the filter characteristics which means that the filter is 
produced from previously reconstructed speech. 

At the encoder, A law or p-law PCM is first converted to linear PCM. The input signal 
is then partitioned into blocks of five consecutive input signal samples. The encoder 
then compares each of 1024 codebook vectors with each input block. The 10-bit 
codebook index of the best match codebook vector is then transmitted to the decoder. 

The decoding operation is also performed on a block-by-block basis. Upon receiving 
each 10-bit index, the decoder performs a table look-up to extract the corresponding 
code vector from the codebook. The extracted code vector is then filtered to produce 
the current decoded signal vector. The five samples of the post filter signal vector are 
next converted to five A-law or p-law PCM output samples. 

Please note that this is a somewhat simplified description of the operation of LD-CELP. 
A more detailed description can be found in G.728 [15]. 

5.5 Conjugate-Structure Algebraic Code Excited Linear Prediction CS- 
ACELP - ITU-T G.729 

CS-ACELP is another speech compression technique that is based upon CELP. It was 
originally designed for packetised voice support on mobile networks although a 
different scheme known as RPE-LTP has been adopted on the GSM mobile telephone 
system (see Section 5.6). 

CS-ACELP operates at a rate of only 8kbit/s yet still provides speech quality similar to 
that of ADPCM at 32kbit/s. Furthermore, in tests it has been shown to operate well 
even when packets are lost. 

The coder operates on speech frames of 10ms, corresponding to 80 samples at a 
sampling rate of 8000 samples per second. For every 10ms frame, the speech signal is 
analysed to extract the parameters of the CELP model (linear prediction filter coeffi¬ 
cients, adaptive and fixed codebook indices and gains). These parameters are then 
transmitted to the destination in a specified frame fonnat. At the decoder, the filter and 
gain parameters are used to retrieve the filter information and simulate the filter. The 
speech is then reconstructed by taking the codebook entry of 80 samples and passing 
it through the reconstructed filter. The speech will then be converted to A or p-law 
PCM and transmitted to the interface. 
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Please note that this is a somewhat simplified description of the operation of 
CS-ACELP. A more detailed description can be found in G.729 [16], 

5.6 Other Compression Techniques 

Continuously Variable Slope Delta (CVSD) - CVSD was one of the earlier speech 
compression schemes designed into TDM multiplexers and was very popular in the 
early 1980s. It is a waveform coder, operating directly on the waveform of the signal. 
However, rather than starting with PCM as is the case with many other compression 
schemes, it often relies on analogue rather than digital techniques. With CVSD coding, 
the sending end compares the analogue input voltage to an internal reference voltage. 
If the input signal is greater than the reference, a “1” is transmitted and the reference 
voltage increased. If the input signal is less than the reference, a “0” is transmitted and 
the reference voltage is decreased. Through this process, the receiver can reconstruct 
the sending end’s reference voltage which itself approximates the input analogue 
signal. Therefore the talker’s analogue signal can also be reconstructed. 

CVSD techniques are not standardised and are proprietary to individual manufacturers. 
CVSD can be used at practically any speed because the bit rate is a function of the 
chosen sample rate. The subjective quality at 32kbit/s is not as good as ADPCM at 
32kbit/s which has thus tended to replace CVSD. The quality degrades even further at 
lower bit rates making CVSD practically unusable at rates of less than 16kbit/s. CVSD 
has poor voice band data support, with DTMF tone transmission becoming unreliable 
at rates of about 16kbit/s. 

Digital Speech Interpolation (DSI) - DSI is the generic term for systems that make 
use of the gaps in speech by stopping the transmission of digitised voice samples and 
thus reducing the effective bit rate of the voice channel. It relies on the probability of 
the speech activity factor (SAF) during a conversation being less than 1. The SAF is 
the amount of time that one person is talking in an average conversation, and is 
normally about 0.4 or 40%. 

An example of where DSI is utilised is in DCME (Digital Circuit Multiplication 
Equipment) as defined in ITU-T G.763. If a particular voice channel is compressed 
using 32kbit/s ADPCM, by applying DSI with an SAF of 0.5, the effective bit rate is 
reduced to 16kbit/s. 

Regular Pulse Excitation-Long Term Prediction (RPE-LTP) - RPE-LTP is a coding 
scheme that has been adopted for use on the GSM (An acronym for Group Speciale 
Mobile and Global System for Mobile communications) mobile telephone system. 
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RPE-LTP operates at 13kbit/s (a recent version operates at 6.5kbit/s). The speech 
quality is reasonable, although not as good as that offered by LD-CELP or CS-ACELP. 
Its main advantage over these other compression schemes is its relative simplicity. For 
this reason, it has also been adopted as a de-facto compression scheme for Internet 
telephony since compression can be performed in real time on PC platforms with, by 
today’s standards, relatively low processing power (e.g. 66MHz 486 computers). 

5.7 Speech Compression Impairments 

The two main impairments introduced by speech compression are those of delay and 
distortion. Delay can be measured easily and we discuss its effects on echo in more 
detail in Section 6. Distortion, on the other hand, is very difficult to measure since it is 
very subjective and can be perceived differently by different listeners. What’s more, 
distortion affects more than just speech. Many speech compression systems are 
optimised for speech and do not carry tones such as signalling tones, or the tones from 
modems and facsimile machines particularly well. 

In order to quantify the amount of distortion resulting from speech compression two 
methods are typically applied: 

5.7.1 Mean Opinion Score (MOS) 

ITU-T Recommendation P.80 (“Methods for Subjective Determination of 
Transmission Quality”) [17], describes methods which are suitable for determining 
how satisfactorily telephone connections may be expected to perform. It includes defi¬ 
nitions of Mean Opinion Scores (MOS) where a number is allocated to the quality of 
a speech path with the meaning of the number given in Figure 5.4. 



Figure 5.4 Mean Opinion Scores (MOS) 
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To get to this number a series of spoken sentences are transmitted to listeners via the 
speech compression system under scrutiny. For each sentence, the listeners must 
allocate a number according to the table in Figure 5.4. The numerical average of the 
results from all the listeners is then used to provide a MOS score for the particular 
speech compression system (See ITU-T P.80 for a more accurate description of this 
process). 



Figure 5.5 MOS for Different Speech Coding Schemes 


While not exhaustive, Figure 5.5 shows a graph of the speech quality achieved with a 
number of different speech coding techniques in terms of their Mean Opinion Scores. 

Note that the use of the term CELP covers a range of different techniques including 
proprietary systems, and standardised ones such as LD-CELP and CS-ACELP. We can 
see that, by using compression schemes such as CS-ACELP, we achieve a similar 
quality to ADPCM at 32kbit/s and regular PCM at 64kbit/s. This general quality of 
speech is often known as “Toll quality”. 

5.7.2 Quantisation Distortion Units (QDUs) 

ITU-T Recommendation G.113 (“Transmission Impairments”) [18] describes a 
method of quantifying distortion on a telephone connection. It defines the Quantisation 
Distortion Unit (QDU) which, by definition, results from one conversion of analogue 
to PCM and back to analogue again (A or ji-law PCM). ITU-T Recommendation G.113 
recommends that no more than 14 QDUs should be introduced in an international 
telephone connection. Currently, there is no method to determine QDU values objec¬ 
tively. It can only be measured subjectively using methods such as those found in ITU- 
T Recommendation P.83 (“Subjective Performance Assessment of Telephone-Band 
and Wideband Digital Codecs”) [19]. 
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When applied to speech compression, the QDU value given represents the equivalent 
number of analogue-PCM-analogue conversions necessary to give the same subjective 
quality as the speech compression scheme. For example, 32kbit/s ADPCM has a QDU 
rating of 3.5 (as given in ITU-T G.113 ). This means that a conversion from analogue 
to ADPCM and back to analogue gives the same subjective quality as 3.5 tandem 
conversions of analogue-PCM-analogue. (The half comes from an averaging process 
used in the assessment of the QDU value). 


Compression Type 

QDUs 

See Note 

64kbit/s PCM 

1 

1 

32kbit/s ADPCM 

3.5 


16kbit/s LD-CELP 

3.5 

2 

PCM-32kbit/s ADPCM-PCM 

2.5 



Note 1 - By definition 

Note 2 - One 16kbit/s codec pair produces a speech quality subjectively equivalent to one 
32kbit/s ADPCM codec-pair, while three lokbit/s codec-pairs produce a speech 
quality approximating that produced by four 32kbit/s ADPCM codec-pairs. 

Figure 5.6 Some QDU Values 


Some speech compression schemes have been allocated QDU values in G.113, a 
selection of which are shown in Figure 5.6. The values for ADPCM and LD-CELP 
include a conversion from analogue to PCM to ADPCM/LD-CELP to PCM and back 
to analogue. 


PBX 2 


PBX 


PBX 



PBX 


Tel A 


“ §=PJI_J | YJ \ J U | \J“ 


PBX 3 


PBX 


SI 


Analogue PCM Compressed 

Speech 


PCM Compressed PCM 

Speech 


Tel B 
Analogue 


Figure 5.7 Tandem Calculation of QDU Values 


For telephone connections which incorporate a number of speech coding/compression 
processes, the QDU values of the individual processes can be added together to 
determine the overall end-to-end Quantisation Distortion. For example, Figure 5.7 
shows a telephone call between telephones A and B which passes via PBXs 1, 2 and 3. 
En route, the speech is compressed twice in multiplexing systems. If, for example, 
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32kbit/s ADPCM is used, then the overall QDU value allocated to this speech path is 6 
which comprises 2.5 from each of the PCM-APDCM-PCM conversions, and 1 from 
the analogue to PCM and back to analogue again. 

5.7.3 Speech Compression and Voice-band Data 

ITU-T Recommendation G.113 discusses the effect of speech compression on voice- 
band data. Currently, only three schemes are covered: LD-CELP at 16kbit/s and 
ADPCM at 32kbit/s and 40kbit/s, although this list will be expanded in the future. The 
following is an extract from G.113 Annex D: 

1) The 16kbit/s LD-CELP (Recommendation G.728) algorithm supports voice- 
band data only up to 2.4kbit/s. 

2) The 32kbit/s ADPCM (Recommendation G.726) supports voice-band data up 
to 4.8kbit/s. 

3) The 40kbit/s ADPCM (Recommendation G.726) supports voice-band data up 
to 9.6kbit/s with 14.4kbit/s for only non-tandem connections. 

This list is intended as general guidance only. In some circumstances, the actual data rates 
supported may exceed those given, although it is equally likely that lower rates will result. 

To put this into context, imagine a V.34 modem which normally operates at a rate of 
28.8kbit/s. Operate this over an ADPCM link at 32kbit/s and the modem may 
downspeed all the way to 4.8kbit/s! 

5.8 Fax Relay 

The ITU-T define a number of different types of facsimile (fax) transmission known as 
Groups 1, 2, 3 and 4. The most commonly used is Group 3 as defined in ITU-T 
Recommendation T.4 and which operates at a data rate of up to 14.4kbit/s. 

Beyond normal telephone conversations, facsimiles represent the second most common 
type of speech-band traffic carried on enterprise networks today. However, we saw in 
Section 5.7 that if carried on circuits using speech compression, the audio tones used for 
fax transmission are distorted sufficiently to reduce the effective data throughput. The 
amount by which this happens depends on the type of speech compression being used. 

Two approaches can be taken to overcome this problem: Firstly, fax traffic can be trans¬ 
mitted on 64kbit/s PCM circuits, although this is very inefficient in bandwidth usage. 
Secondly, a technique such as fax relay can be used where the fax tones are first demod¬ 
ulated and transmitted as actual data rather than as digitised speech band tones. Not 
only does this allow the full speed operation of the fax but also offers additional 
bandwidth savings over the use of some speech compression schemes. 
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Multiplexer 1 Multiplexer 2 



Figure 5.8 Fax Relay Operation 

The operation of fax relay is demonstrated in Figure 5.8. The speech interfaces at the 
two multiplexers can either be analogue or digital depending upon the system in use. 
If digital, then in practice, the fax relay function would apply to all channels carried in 
the digital signal. 

Audio signals arrive at the interface of Multiplexer 1 (or Multiplexer 2 if the call orig¬ 
inates from that end). If the signal is speech, then it is directed towards the speech 
compression section. However, if it is a fax signal, then it is directed towards the fax 
demodulation function which literally demodulates the fax signal into a corresponding 
data signal and then transported over the wide area network as data. At the destination, 
this data is then converted back to an audio fax signal for onward connection to the 
destination fax machine. 

The detection of the fax signal is normally done automatically by monitoring the audio 
signal, first of all for a 2100Hz tone followed by a fax call preamble. This preamble 
represents data communicated between the two end fax machines and used to set up the 
call. It carries such information as the fax machine’s telephone number, its capabilities 
such as speed ability, and so on. 


40 


Section 5 - Speech Compression 



















Voice Fundamentals: From Analogue to ATM 


6.1.1 Causes of Echo 

There are two main factors that contribute to echo. Firstly, the delay introduced by the 
network carrying the speech communications path and secondly any point in the 
network that reflects the speech signal. Without the delay, the reflection is not a 
problem, and without the reflection the delay is not a problem. 

In Figure 6.2 we can see a typical speech path between two telephone sets and the most 
common cause of echo i.e. hybrid echo. Both telephones in this example are two wire 
sets, i.e. they connect to the exchange over a single pair of wires. At the exchange, the 
two wire path is converted into a four wire path using a hybrid (see Section 2.2) and 
the speech is transported over the wide area to another exchange using a four wire path. 
At the other exchange, the four wire path is converted back to two wire for connection 
to the other telephone. In Section 2.2 we saw that this conversion from a four wire to 
a two wire path and vice versa is imperfect. If the impedance presented by the phone 
and the line does not perfectly match the impedance of the exchange interface, then 
some signal is certain to be reflected. 


Echo 



We can see this in Figure 6.2 where the speech signal from Telephone A is converted 
from the two wire path to the four wire path, transported across the telephone network, 
and converted back to a two wire path onto Telephone B at the destination. At 
Telephone B’s hybrid, some of the signal is reflected back towards Telephone A. 

In practice, there are multiple points of reflection in a network as shown in Figure 6.3. 

We have assumed a four-wire path between Telephones A and B. Even for a simple call 
there are many potential points of reflection: a) represents the reflected signal at the 
hybrid internal to Telephone A which should simply be perceived as sidetone, b) is the 
signal reflected at the hybrid of the telephone exchange to which Telephone A is 
connected and again should be perceived as sidetone, c) is the reflected signal from the 
hybrid at the far end exchange interface, and d) the reflected signal from the hybrid in 
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Figure 6.3 Various places that echo occurs 

Telephone B. Both c) and d) represent reflected signals that will be perceived as echo 
if the round trip delay exceeds a threshold (about 30ms). 

A common misconception is that these are the only causes of reflections. While the 
reflections at c) and d) are normally the dominant ones contributing to echo, there is 
also a significant effect from the acoustic coupling between the mouthpiece and 
earpiece of Telephone B. Furthermore, with today’s increased use of handsfree phones 
in both static and mobile systems, acoustic echo is becoming more of an issue. 

Note that this example shows a four wire path between the two ends which, in today’s 
digital networks is the most likely arrangement. If for any reason, however, the trans¬ 
mission path includes any other two wire circuits, then these will give additional reflec¬ 
tions back to the source telephone. 

6.2 Echo Control Devices 

6.2.1 When Do We Need Echo Control 

In practice, echo control is needed when the round-trip delay of a voice communica¬ 
tions system exceeds 20-30ms. While not an exhaustive list, the following describe 
some of the primary causes of delay in voice networks today: 

International circuits - Due to the sheer distances involved, some delay is inevitable 
and so these circuits will usually require echo control. Satellite circuits will definitely 
require echo control since the round trip delay caused by a single satellite hop is 
typically in excess of 500ms. 
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Frame/Cell based systems - Many frame/cell based systems such as frame relay or 
ATM will require echo control because of the delays imposed by storing up voice 
samples before transmission. Furthermore, additional delay is imposed by the de-jitter 
buffers. These are used at the output of the network to overcome problems caused by 
frames/cells arriving from the network at irregular times. 

Speech Compression - Some speech compression techniques impose significant 
delays because of the time it takes to perform the compression as well as the need to 
store up speech samples. For example, CS-ACELP (ITU-T G.729) which compresses 
speech to 8kbit/s introduces a one way delay of approximately 15ms. 

Some typical one-way delays from various causes are as follows: 

Cable (Copper or fibre) - 1ms per 200km 

Digital Switch - 0.75 - 1.6ms 

Speech compression - 0.5 - 100ms 

Satellite hop - 250ms 

Frame/Cell based system - up to 50ms 

6.2.2 Echo Control Devices 


Echo 



Figure 6.4 Position of Echo Control Device 

There are primarily two techniques used for controlling echo: Echo suppression and 
echo cancellation. In both cases, the echo suppressor and echo canceller sit in the four 
wire path of a communications network as shown in Figure 6.4. 

As we saw earlier, the primary (although not only) source of echo is the 2 to 4 wire 
hybrid at the two wire telephone interface. Therefore, speech from Telephone A is 
reflected as echo at the 2 to 4 wire hybrid at exchange 2 and vice versa. It is the respon¬ 
sibility of echo control device 1 to remove the echo caused at exchange 1 and similarly 
for echo control device 2 and exchange 2. i.e. for echo to be removed for a particular 
user, it is the responsibility of the far end echo control device. 

This raises an interesting point. Since the echo control device will be removing echo 
from its local tail, then the transmission delay (the delay between echo control devices) 
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has no bearing on its performance. In fact, the transmission delay could be many 
seconds and the echo control device will still work, although in practice, a delay of this 
length would be unusable from the point of view of the users. 

6.3 Echo Suppressors 

Echo suppressors are relatively simple devices used for echo control. First devised some 
30 years ago they are still used in some transmission networks today. They have been 
standardised in ITU-T Recommendation G.164 [20] and basically operate as follows: 

An echo suppressor is designed to remove the echo as shown in Figure 6.5. It does this 
by placing a large loss (attenuation) in the transmit path when it detects a signal on the 
receive path. While this reduces the level of the returned echo, its main drawback is that 
it will also prevent the speech from Telephone A reaching the remote party when both 
parties are talking simultaneously (termed “double-talking”). To reduce this effect, 
during double-talk, the echo suppressor must be able to operate in a second mode, 
where the transmit attenuation is reduced to a very small value and a small amount of 


Echo Suppressor 



Figure 6.5 Echo Suppressor 

attenuation is also placed in the receive path. In this way, while the received speech is 
now reduced in level slightly, the echo is effectively attenuated twice due to both the 
receive and transmit attenuations. Furthermore, during double-talk, the echo will tend 
to be masked out by the speech from Telephone A anyway. 

Nevertheless, echo suppressors, while reducing echo, impare the quality of the speech 
communication, and for this reason have been superseded to a large extent by the 
superior echo canceller. 

6.4 Echo Cancellers 

As with the Echo Suppressor, an Echo Canceller is a voice operated device connected 
on the four wire side of a circuit. Its operating performance has been standardised in 
ITU-T G.165 [21]. However, rather than attenuating the echo, it calculates an estimate 
of what the echo will be, and then subtracts this from the actual returned signal. In this 
way, only the echo is removed, while the wanted signal is unaffected. 
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Echo Canceller 



Tail Circuit 

Figure 6.6 Echo Canceller 

Figure 6.6 shows the operating principles of an echo canceller. Remember that this 
canceller will cancel the echo on its local tail circuit, i.e. the echo being returned from 
the hybrid towards Sin. 

The echo canceller operates by developing a mathematical model of the echo that it 
anticipates will occur and subtracting this from the signal in the echo return path i.e. 
the signal into Sin. Essentially this model is based upon two main factors: Firstly, the 
difference in the signal level out of Rout and the echo returned to Sin, also known as 
the Echo Return Loss (ERL), and secondly, the round trip delay of the tail circuit. The 
process of developing the model is known as convergence. (Note that this is a fairly 
simplistic view, because echo cancellers also need to be able to cope with multiple 
echoes occurring at different times and at different levels). 

For example, if the round trip tail circuit delay is 5ms, and the ERL is lOdB (i.e. the 
echo into Sin is lOdB less than the signal out of Rout) then the echo canceller will store 
the signal seen on Rin in memory for 5ms and replay it into the subtractor at a level of 
lOdB less than at Rin. In this way, only the echo is cancelled without affecting the 
speech from Telephone A. 

In practice, this cancellation process is not perfect, and a small amount of echo, known 
as residual echo usually remains at the output of the subtractor. To remove this residual 
echo, an additional function known as the nonlinear processor (NLP), is used. 

6.4.1 Nonlinear Processor 

The function of the nonlinear processor is to take a signal in from the echo subtractor, 
and, if it is of sufficiently small value, stop it passing completely. The method of imple¬ 
menting this function is up to the manufacturer of the echo canceller. 
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However, one method described in G.165 
is known as a centre clipper and is shown 
in Figure 6.7. Here, signals that are larger 
than the clipping level are let through 
without change, while signals that are 
smaller are reduced to zero level. The 
effect of this is to practically reduce the 
echo to zero. 


6.4.2 Tail Circuit Considerations 

The tail circuit capability (or round-trip 
delay) of an echo canceller is primarily 
dictated by the length of time that it can 
store the synthetic echo for. In a digital echo canceller, this will be linked to the amount 
of memory used and is typically in the region of 8 - 128ms. 

If the actual tail circuit delay exceeds the capability of the canceller, the canceller will 
be unable to store the synthesised echo signal for long enough, and the echo will not 
be cancelled. In practice this is a common cause of poor echo canceller performance. 

For example, Figure 6.8 shows an international network where echo cancellers are used 
to overcome the echo caused by long distance transmission delay. A call from 
Telephone A to Telephone B may be echo free, yet a call from Telephone A to 
Telephone C results in echo at Telephone A. The reason for this is that the extra delay 
for the call to Telephone B, exceeds the tail circuit capabilities of the echo canceller. 

To overcome this problem, the tail circuit capability of the echo canceller could be 
increased by adding additional memory (assuming this is possible), or another echo 
canceller may be put in the circuit closer to Telephone C. 



Figure 6.7 The Nonlinear Processor 
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6.4.3 Types of Echo Canceller 

Up until now, we have been considering and, through example, demonstrating echo 
cancellers operating on individual speech channels. 

In practice, there are many different types of echo canceller operating on either 
analogue or digital signals. G.165 describes three types: Types A, C and D and 
described as follows: 

Type A - An echo canceller that operates on one analogue speech circuit using 
analogue techniques to cancel the echo. 

Type C - An echo canceller that operates on a 64kbit/s digital signal and uses digital 
signal processing techniques to cancel the echo. However, today, devices called bulk 
echo cancellers are quite common. These devices combine 24 or 30 digital echo 
cancellers for 1.544Mbit/s and 2.048Mbit/s digital voice trunks. An example of the 
logical operation of a canceller is shown in Figure 6.9. 



Figure 6.9 1.544Mbit/s, 24 Channel Bulk Echo Canceller 

Type D - An echo canceller that operates on one analogue speech circuit yet converts 
the signal to digital PCM for cancellation and then re-converts the signal back to 
analogue. This type of echo canceller is common today for situations where single 
analogue circuits need echo control. 

6.4.4 Tone Disabling of Echo Cancellers and Echo Suppressors 

Under certain circumstances, it is important that echo suppressors and echo cancellers 
are automatically disabled. One such instance is in the presence of voice band data 
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traffic from modems and facsimiles. The operation for suppressors and cancellers is 
different and is as follows: 

Echo Suppressors - Echo suppressors are designed to be automatically disabled, in 
order to prevent the introduction of suppression and receive loss when data or other 
specified tone signals are transmitted. Most modems and fax machines, when they start 
up, transmit a 2100Hz tone. Upon detecting this signal the echo suppressor will auto¬ 
matically disable itself. The echo suppressor will then stay disabled throughout the data 
phase and until the circuit goes quiet, at which point it re-enables itself. 

Echo Cancellers - The operation is slightly different for echo cancellers, since for low 
speed modems (<9600bit/s) echo cancellation can improve the effective signal to noise 
ratio and thus improve the bit error ratio achieved. This is also the case for Group 3 fax 
machines (9600bit/s - V.29). It is therefore preferable that echo cancellers do not 
disable in the presence of these low speed devices. However, for modems faster than 
9600bit/s (V.32, V.32bis, V.34 etc.) there is no improvement in the signal to noise ratio 
and it is better for the echo canceller to be disabled (These types of modems already 
have echo cancellation built in anyway). 

In order that an echo canceller can differentiate between the types of modems in use, 
and therefore the speed of data transmission, V.32 and faster modems still start up with 
a 2100Hz tone, yet in this case this tone includes a series of phase reversals which the 
echo canceller can recognise (the phase reversals are defined in ITU-T V.25). Therefore 
an echo canceller will disable for 2100Hz tones with phase reversals, but not disable if 
only a simple 2100Hz tone is detected. 

6.4.5 G.168 (Improved Echo Canceller) 

As of the time of writing of this booklet, a new ITU-T Recommendation, G.168, has 
just been issued in draft form and is shortly expected to be approved by the ITU-T 
membership. G.168 defines the performance of what has become known as the 
Improved Echo Canceller. 

G.165 has long been the benchmark recommendation for echo cancellers. However, 
networking technology has moved on at such a rate that an echo canceller performing 
to G.165 alone is often not capable of dealing with many of today’s real-life voice 
networking issues. Resultingly, G.168 has been produced to address these issues and 
ensure that an echo canceller will perform adequately under wider network conditions 
than as specified in G.165. 

However, even though G.168 will soon be approved, there are a number of areas that 
are still for further study. Meanwhile, G.168 is currently deemed as being in a suitable 
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state for release due to its significant improvements above and beyond G.165. Some of 
the key areas addressed are as follows: 

Use of Composite Source Signal - In determining the performance of echo cancellers, 
many of the tests defined in G.168 use a new test signal known as the Composite 
Source Signal (CSS). The CSS has been chosen because it produces test results that are 
similar to those that real speech would produce. This is in contrast to the white noise 
source as used in G. 165 which, in practice, does not produce very realistic results. 

Operation for Higher Level Signals - A G.165 echo canceller does not define require¬ 
ments for handling signal levels in excess of -KMBmO. In the past, this has not been a 
problem, since the average levels in a public voice network have been in the region of 
-16dBmO to -28dBmO. In today’s digital networks however, particularly private 
networks, the average levels have increased to between -lOdBmO and 
-22dBmO. This can lead to the misoperation of echo cancellers. This situation is taken 
into account by G.168, which caters for signal levels up to OdBmO. 

Improved Convergence Time - G.165 used a white noise source to assess the conver¬ 
gence performance of an echo canceller. In practice this was found to be reasonably 
ineffective, resulting in some echo cancellers that would take a significant time to 
converge on real speech echoes. G. 168 uses the CSS and tightens up on the test require¬ 
ments for convergence time. Three tests are included catering for situations with the 
Non-Linear Processor (NLP) both enabled and disabled and when echo exists in the 
presence of noise. 

Injection of Comfort Noise - Although the use of a nonlinear processor (NLP) is not 
required in an echo canceller, without it the echo cancellation performance is limited. 
The main problem with the NLP is, that during operation, all signals including low 
level background noise are removed. Normally a user would not even notice this back¬ 
ground noise. However, when it is cutting in and out due to the operation of the NLP, 
the effect can be quite irritating. A G. 168 canceller recognises this problem by allowing 
“comfort noise” to be injected into the transmit path (towards the network and the far 
end talker) of the echo canceller during the time that the NLP is activated. 

Proper Operation During Facsimile Transmission - In recognition of the significant 
use of facsimile traffic in networks today, a number of tests have been defined in G.168 
to ensure that an echo canceller will quickly converge on signals from facsimile 
machines. 

Please note that the list given above does not include all the tests that are given in 
G.168. We suggest that reference is made to G.168 itself for a more in-depth under¬ 
standing of all the performance requirements for a mod echo canceller. 
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7 Introduction to Signalling Systems 

The previous sections have established many of the basic building blocks of telephony. 
This section looks at the wide variety of signalling techniques used for call control in 
several situations, including between telephone exchanges and most specifically 
between financial dealing systems. 

We begin with a look at some of the analogue signalling systems still in use today. This 
includes PBX interfaces as well as interfaces used in financial dealing environments 
where analogue interfaces are still used extensively. We complete the section with a 
look at digital signalling including Channel Associated Signalling (CAS) and Common 
Channel Signalling (CCS) and some examples of both types of system. 

7.1 Analogue Signalling Systems 

A long time before digital techniques were developed, signalling systems were 
analogue based. While today most voice communication employs digital telephone 
exchanges, there are still a large number of analogue interfaces in use. Except for where 
ISDN is installed, all domestic telephones still use analogue signalling such as that 
described in Section 2.2. Some even use Loop Disconnect dialling as opposed to 
DTMF. Many organisations, especially financial trading companies who require 
dedicated point-to-point voice connections, still use a large number of analogue inter¬ 
faces. In fact, in today's “high-tech” world of fast computers and high speed digital 
communications, it comes as a great surprise to many that there is still so much 
analogue technology being used. What's more, this situation will probably continue for 
many years to come. 

The most common PBX trunk signalling methods available are Loop Start/Loop 
Disconnect (see Section 2.2), Ground/Earth Start, E&M and AC 15. 

7.1.1 Ground Start: 2 Way PBX to Public Exchange Trunk Circuit 

A Ground Start trunk from a public exchange can be used to connect to either a 
telephone set or to a PBX, although the latter is more common today. Ground Start is 
a modification of Loop Start, and is used to limit the likelihood of a call collision, or 
“glare”. This is where both ends seize (begin to use) the circuit simultaneously. On a 
Loop Start circuit, this is most likely to occur when the exchange seizes the circuit at 
the start of the quiet interval in the ring cycle. This should not be too great a problem 
with a simple telephone line since there is a good chance that the incoming call is for 
the person attempting to make the outgoing call. However, on a shared trunk as used 
with a PBX, it could result in two people being connected, neither of whom want to 
speak to the other. 
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Ground Start signalling minimises the chance of glare by adding additional signals 
including the application of a ground/earth to one of the leads to indicate an incoming 
call. The PBX uses this, rather than the intermittent ringing, to identity the incoming 
call. Once detected, the PBX will prevent any outgoing calls on the same circuit. 

The following passage describes the signalling sequences between a public exchange 
and a PBX Ground Start trunk, for calls in both directions: 

Outgoing Call From PBX: 

1) The PBX applies a Ground/Earth to the Ring/B lead to seize the trunk. 

2) The Exchange busies the trunk and acknowledges the seizure by applying a 
Ground/Earth to the Tip/A lead. Dialtone may be returned. 

3) The PBX removes the Ground/Earth condition from the Tip/A lead and 
applies a DC loop between Tip/A and Ring/B. 

4) The PBX dials the outgoing number by pulsing the loop on and off or by 
transmitting DTMF tones. 

Incoming Call to PBX: 

1) The exchange grounds the Tip/A lead to seize the trunk. 

2) The exchange applies ringing to the Ring/B lead. 

3) The call arrives at the PBX operator/attendant. 

4) To answer the incoming call, the PBX applies a DC loop between Tip/A and 
Ring/B. 

Note that in both cases, the call in progress state is the same as for Loop Start. This is 
important, since if the PBX fails, for example due to power loss, it is still possible to 
make outgoing emergency calls. In this case, the PBX should automatically switch the 
trunk to a telephone set with Earth Recall facility. Pressing the Earth Recall button on 
the telephone will apply a ground to the Ring/B lead just as if the PBX were making 
an outgoing call. The telephone set would then provide a holding loop and then send 
the digits using pulsing, or DTMF. 

7.1.2 E&M Trunk 

Most PBXs, as well as other types of equipment such as financial dealing systems 

(dealer boards) offer analogue E&M signalling interfaces. E&M interfaces come in two 
forms, two wire E&M and four wire E&M. Two wire E&M normally uses four physical 
connections including two for the two wire voice plus the E and M signalling leads. Four 
wire E&M nonnally uses six physical connections including two pairs for the four wire 


52 


Section 7 - Introduction to Signalling Systems 






Voice Fundamentals: From Analogue to ATM 

FCS - Frame Check Sequence. Used for error detection. 

End Flag - A bit pattern of 01111110 used to identify the end of the message. 

Layer 3 

Protocol Discriminator - This specifies the protocol that should be used to interpret 
the information within this particular message. 

Call Reference - Uniquely identifies the call that this message relates to. 

Message Type - Identifies the type of message e.g Setup, Connect, Disconnect etc. 




Figure 7.6 Message flows for basic call setup with QSIG 


Other Information Elements - Provides additional information depending upon what 
type of message is being sent. e.g. Called Number, Calling Number, type of call (voice, 

voiceband data, data etc), Channel (timeslot) Identification etc. 

In order to demonstrate the operation of CCS, we shall look at an example of a basic 
call setup using QSIG between two PBXs. Figure 7.6 shows the layer 3 messages trans¬ 
ferred across the link. It does not show the underlying layer 2 messages that are used 
to ensure reliable, error free communication across the link. 
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To initiate a call, the user of Telephone A picks up the handset and dials a number that 
corresponds to Telephone B. PBX 1 identifies that Telephone B can be reached via the 
digital trunk. The following layer 3 messages are then passed across the trunk between 
the two PBXs: 

Setup - Used to initiate call establishment. It contains various Infonnation Elements 
that define parameters such as the destination number, the calling number, the type of 
call, the timeslot on which the call will be carried and others. 

Call Proceeding - Sent to the calling PBX to indicate that the requested call establish¬ 
ment has been initiated and no more call establishment information will be accepted. 

Alerting - Inf orms the calling PBX that the called user is being alerted. The PBX will, 
for example, apply ring-back tone to the calling user. 

Connect - Indicates that the called user has answered the call and that the calling party 
can be connected to the agreed traffic channel. 

Connect Acknowledge - Used to acknowledge receipt of the Connect message. 
Disconnect - Used to request that the connection be cleared. 

Release - Indicates that PBX 2 has disconnected the channel and intends to release the 
channel and the call reference on receipt of the Release Complete message. 

Release Complete - Indicates that PBX 1 has released the channel and call reference. 
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Voice over Asynchronous Transfer Mode - ATM was chosen by the ITU-T as the 
communications technology upon which Broadband-ISDN would be based. It was 
chosen because of its ability to support all communications requirements including 
voice, video and data, and because it is scalable from speeds as low as a few Mbit/s up 
to many Gbit/s. We shall discuss ATM in more depth in Section 9. ATM offers the 
ability to provide the low delays and the low delay variations that are required for 
voice transmission. 

Voice over Frame Relay - As a technology, frame relay was originally designed as a 
high speed version of X.25 suitable for efficient transfer of data across a Wide Area 
Network (WAN). Since its introduction in the early 1990’s the use of frame relay has 
grown at an almost exponential rate. 

Up until recently, it was not widely believed that frame relay was a suitable technolo¬ 
gy to support speech. This was due to factors such as unpredictable delay and the possi¬ 
bility of frames of data being discarded in the network. This came about because early 
frame relay networks, based on medium-speed backbone links, were not particularly 
well suited to speech. However, today’s frame relay networks are often fonned using a 
frame relay interface and a cell based backbone. These backbones are typically high 
speed networks based on technologies such as ATM which provides fast, predictable 
delivery of time-sensitive information. Today, speech support over frame relay is 
becoming more and more popular, to the extent where the frame relay Forum has set 
up a sub-committee to define standards. 

Section 10 of this booklet discusses voice over frame relay. 

Voice over X.25 - X.25 packet switching was first standardised in 1976 as a means to 
transport data reliably, via modems, across inherently noisy analogue lines. It incorpo¬ 
rates techniques, or protocols, which ensure that data carried by the network will 
successfully reach its destination, error free. Even if the data becomes corrupted, the 
network will automatically re-transmit it without the user knowing. This capability 
adds a significant overhead to transmissions by introducing large delays and, in the 
case where re-transmissions occur, variable delays. For these reasons X.25 is not a 
suitable technology for voice support. 

Voice over IP - Today, Internet Protocol (IP) networks have practically become the 
corporate standard for LAN and WAN data traffic with users ranging from small home 
office operators to large multinational organisations. As IP networks have grown in 
popularity, they have developed to support a wide range of applications and services. 
Up until now, most of these have been data orientated, however, other real-time 
requirements including the support of voice and video are developing. 

While the support of voice over IP is still in its infancy, Section 11 looks at how it 
operates and some of the issues involved. 
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8.2 Time Division Multiplexers (TDM) 

TDM technology has been with us ever since the development of channel banks where 
a number of analogue voice channels are digitised and each one allocated a specific 
timeslot on the link between two channel banks. This is the essence of the framed El 
and DS-1 digital voice trunks as shown in Figures 4.5 and 4.8/4.9. This is time division 
multiplexing in its simplest form. 

However, when referring to TDMs, we usually mean multiplexers which provide 
communication between many locations served by the multiplexer network (e.g. as in 
Figure 8.1). The method used for communication between one multiplexer and the next 
usually conforms to some format proprietary to the product manufacturer. This is to 
allow a wide range of channel speeds to be supported rather than being orientated 
around 64kbit/s as with DS-1 and El. The connection between two multiplexers is 
often called the aggregate link and will typically cover a wide range of speeds from as 
low as 9.6kbit/s up to many Mbit/s, depending upon the specific system. Multiple links 
may be used to support the bandwidth demands and/or for resilience. 

The term TDM comes from the method by which channel information is multiplexed 
onto the aggregate links. A simple view of this is shown in Figure 8.2. 

As with G.704 and D4/ESF framing for digital PBX connections, a TDM link uses data 
frames which consist of a series of timeslots. However, the frame length, number of 



Figure 8.2 Typical TDM Frame 



timeslots and frame repetition rate is usually proprietary to the equipment manufactur¬ 
er. Figure 8.2 shows how data from a number of channels may share the bandwidth on 

an aggregate link. 

The timeslots within the frame will provide a particular bandwidth depending upon the 
frame repetition rate and the number of timeslots per frame. For example, each timeslot 
may represent a bandwidth of lOObit/s. This would mean that the 9.6kbit/s channel 
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would require 96 timeslots per frame, the 19.2kbit/s channel would use 192 timeslots 
and the 64kbit/s PCM channel, 640 timeslots per frame. 

In addition to the actual data, other information needs to be carried in the frame 
including the following: 

- Frame synchronisation bits. 

- Supervisory communications data between the multiplexers to carry alarms, 
status, maintenance and configuration information. 

- Signalling for the channels e.g E&M for voice, RTS/CTS for data etc. 

The actual layout of the frame will be determined by a number of factors including the 
number and speed of channels, amount of supervisory overhead, the speed of the 
aggregate etc. Once a frame is built for a particular configuration it will remain 
unchanged until one or more of the parameters change. As a result, one of the drawbacks 
of a TDM is that, if a device stops sending data into a particular channel, and unless the 
multiplexer is reconfigured, timeslots are still allocated which wastes bandwidth. 

8.2.1 TDM Synchronisation 

In Section 4.5 we saw that PBXs linked via digital connections need to be synchro¬ 
nised, otherwise errors will occur which will usually result in noise or clicks on the 
voice. The same is true for TDM multiplexers. They are also synchronous devices and 
often use clock fallback lists in the same way as PBXs. In fact, synchronisation issues 
are one of the biggest contributors to TDM network problems today. 


PBX 2 



Figure 8.3 PBX & TDM Synchronisation 
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We can take this concept one step further by considering the operation of a network of 
PBXs connected, using digital trunks, via a TDM network. In this case all the PBXs 
and multiplexers need to be synchronised to the same network clock. 

This is not difficult, since it is usual to have at least one digital link from a PBX into the 
public carrier network for PSTN access. These links should provide the PBXs with highly 
accurate Stratum 1 (1 part in 10 11 ) clock sources, each of which is derived from the same 
source and so they are all synchronised. The PBX can then provide this clock to the TDM 
multiplexers for synchronisation. An example showing this is given in Figure 8.3. 
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9 Voice Over Asynchronous Transfer Mode (ATM) 

Today, ATM is beginning to grab a significant portion of the networking market and 
interest in the support of voice is growing rapidly. As a result, a number of standards 
are being developed for the support of what has now become known as Voice and 
Telephony Over ATM (VTOA). 

This section looks at how voice can be supported using some of the existing mecha¬ 
nisms designed for the support of various traffic types over ATM. Before looking at 
how voice is supported specifically, we will first provide a brief introduction to ATM. 

9.1 Introduction to ATM 

ATM is the technology that was originally chosen by the ITU-T to support the 
Broadband ISDN (B-ISDN). It is defined by the ITU-T in Recommendation 1.113 
("Broadband Aspects of ISDN" [12]) as being "A service or system requiring trans¬ 
mission channels capable of supporting rates greater than the primary rate" 
(1.544Mbit/s or 2.048Mbit/s). ATM was chosen because of its ability to handle all types 
of traffic including voice, video, image and data within a single network. 

In 1991, the ATM Forum was formed with the objective of accelerating the use of ATM 
products and services through a rapid convergence of interoperability specifications. 
ATM Forum specifications refer extensively to ITU-T Recommendations and, as such, 
much reference is made to some of these Recommendations in this booklet. For 
example, it is the ATM Forum who, today, are developing the standards for voice over 
ATM, known as Voice and Telephony Over ATM (VTOA), although the standards refer 
extensively to various ITU-T Recommendations. 

ATM is a compromise between traditional circuit switching and packet switching. It 
offers the asynchronous nature of packet switching, where data is only sent when it 
needs to be, while requiring connections to be set up before any data is actually sent, 
as with circuit switching. 

9.1.1 The ATM Cell 

ATM makes use of fixed length packets, called cells, for transportation of all traffic 
over the network. The ATM standards define a 53 byte cell with a 5 byte header and a 
48 byte payload. This provides a balance between shorter cells for delay sensitive 
traffic such as voice and video, and longer cells for delay tolerant traffic such as inter- 
LAN data. Two cell formats are defined: one for an interface between two ATM 
networks (NNI - Network-to-Network Interface or Network Node Interface), and one 
for the interface between an ATM network and a user or user network (UNI - User 
Network Interface). Both of these formats are shown in Figure 9.1. 
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Generic Flow Control (GFC) - Available for flow control at the UNI. 

Virtual Path Identifier (VPI) - Used as part of addressing function. 

Virtual Channel Identifier (VCI) - Used as part of addressing function. 

Payload Type Indicator (PTI) - Identifies the type of cell plus other functions. 

Cell Loss Priority (CLP) - Indicates whether the cell may be discarded during congestion. 
Header Error Control (HEC) - CRC check to detect errors in the header. 

Figure 9.1 ATM NNI and UNI Cell Formats 


These fixed length cells bring many benefits including the ability to switch the data at 
extremely fast speeds using hardware, the statistical multiplexing of data from many 
sources and a very wide range of transmission speeds ranging from as low as 
1.544Mbit/s up to 2.488Gbit/s and beyond. 


9.1.2 The ATM Adaptation Layers 

The process of inserting actual user traffic into the ATM cell and extracting it at the 
destination is accomplished by the ATM Adaptation Layer (AAL) as defined in ITU-T 
Recommendation 1.363 [13]. This function lies in the end ATM devices, and is not a 
function of the network itself. The network deals purely with switching ATM cells. 

A number of different AALs have been defined to deal with the many different types 
of user traffic. The choice of AAL depends upon the nature of the traffic i.e. whether it 
is variable or constant bit rate, connection-oriented or connectionless and whether a 
timing relationship is required between the source and the destination. Currently four 
AALs have been defined including AAL 1, AAL2, AAL3/4 and AAL5. 

To demonstrate the function of AALs, Figure 9.2 shows a simple point-to-point ATM 
network with connections to a PBX and to a LAN. Traffic from each interface is 
converted to a form that will fit into ATM cells through the use of the ATM Adaptation 
Layer (AAL). The cells are then transmitted to the trunk interface from where they are 
sent onto the destination. Due to the different nature of the traffic originating from the 
PBX and from the LAN, two different AALs are used, namely AAL 1 and AAL5. 
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Figure 9.2 A Simple ATM Network 


AAL1 - AAL1 was devised to support circuit emulation and provides a service to the 
attached equipment equivalent to a leased line. In ATM terminology, this is known as 
a Constant Bit Rate (CBR) service and is demonstrated in Figure 9.3. In effect, AAL1 
is a continuous process where cells are filled from the interface and transmitted at 
regular intervals into the ATM network. To support these regularly transmitted cells, a 
fixed bandwidth needs to be allocated within the ATM network. 
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Figure 9.3 Voice Transport viaAALl Circuit Emulation 


The 1.544Mbit/s (DS-1) or 2.048Mbit/s (El) bit stream from the PBX is chopped up 
into blocks of 47 bytes, and a 1 byte AAL header is added. This header basically 
contains a sequence number which will be used by the destination to detect missing or 
misinserted cells. The combination of 48 bytes is then inserted as the payload into the 
ATM cell and transmitted to the destination. The next 47 bytes are then dealt with in 
the same way and so on. 

At the destination, the 48 byte payload is extracted from the ATM cell and the ATM 
header discarded. The one byte AAL header is inspected to ensure that no error has 
occurred and the 47 byte data is transmitted to the PBX interface. If, for example, a cell 
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is found to be missing, then it needs to be replaced with a dummy cell to ensure timing 
integrity of the interface connected to the PBX. The content of the dummy cell will 
depend upon the actual application, however for circuit emulation of 1.544Mbit/s and 
2.048Mbit/s circuits, the contents should be all “l”s. 

This description covers what is known as an unstructured AAL1 service. AAL1 also 
allows a structured service where additional information is carried to allow the delin¬ 
eation of a structure of the information carried within the payload. Please refer to 
ITU-T 1.363 for further details. 

AAL5 - In the case of traffic from a LAN, it is not appropriate to use AAL1 since the 
information arrives at irregular intervals and is in the form of a block of data known as 
a frame. In this case we can use AAL5 to perform the process of adapting the LAN 
frames to fit into ATM cells. Figure 9.4 demonstrates the operation of AAL5. AAL5 
takes user data, in this example a 218 byte LAN frame, and adds some overhead, which 
includes some padding data and an AAL5 trailer. This produces a new frame that is a 
multiple of 48 bytes. It then segments the frame into blocks of 48 bytes each and inserts 
them into the payload of the ATM cells. An ATM header of 5 bytes is added, and the 
cell is transmitted into the network and onto its destination. 

Please note that, in contrast to AAL1, AAL5 is not a continuous process. Cells are only 
transmitted when there is a frame to send. When there are no frames, no cells are 
generated and no bandwidth is consumed in the ATM network. 
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Figure 9.4 ATM Adaptation Layer Example - AAL5 
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9.1.3 ATM Service Categories 

Within its Traffic Management Specification (currently version 4.0) [28], the ATM 
Forum defines five service categories available for use to transport different types of 
traffic across an ATM network. These include: 

- Constant Bit Rate (CBR) 

- Real-Time Variable Bit Rate (rt-VBR) 

- Non Real-Time Variable Bit Rate (nrt-VBR) 

- Unspecified Bit Rate (UBR) 

- Available Bit Rate (ABR) 

The reason that there are multiple categories is to cater for different characteristics and 
different Quality of Service (QoS) requirements associated with different traffic types. 
For example, speech has a real-time characteristic and requires guaranteed bandwidth 
and minimal delay, while most data types are non real-time and do not necessarily 
require a guaranteed bandwidth and can often tolerate significant delays. For purposes 
of brevity, the detailed description of each category is not covered in this booklet and 
we would refer you to the ATM Forum Traffic Management Specification [28] for more 
details. 

However, as far as voice is concerned, it can be treated in a number of ways. If we 
consider a flow of speech as described in Section 9.1.2 using AAL1, this represents a 
CBR service, since there is a constant flow of information and it requires particular 
QoS parameters. However, voice can also be treated as rt-VBR by exploiting the fact 
that in a typical conversation, there are significant gaps (due to gaps between words and 
while the other person is talking). This can be seen graphically in Figure 9.5 where the 
left hand graph shows a constant flow of speech samples including samples represent¬ 
ing silence (CBR), whereas the right hand graph shows bandwidth only being used 
while the person is actually talking (rt-VBR). In practice, the actual amount of 
bandwidth used will vary depending upon what is being spoken, hence the term VBR. 
Section 9.2.4 looks at a feature, known as Speech Activity Detection (SAD), that 
exploits this VBR nature of speech. 



Figure 9.5 Constant Bit Rate vs. Variable Bit Rate 
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9.1.4 Statistical Multiplexing with ATM 

One of the key benefits of using ATM in preference to other technologies is its ability 
to statistically multiplex all types of traffic onto the same data link. Figure 9.6 shows a 
comparison between bandwidth utilisation on TDM and ATM links, both of which are 
carrying voice, LAN and SNA channels. 

In the case of TDM, there is a finite amount of bandwidth allocated to each channel. 
The channel cannot exceed its allocated bandwidth and even if it is not being used at a 
particular time, the resulting unused bandwidth cannot be used by any other channel. 

This is in contrast to ATM where, at any time, the overall bandwidth used is the sum of 
the instantaneous bandwidths of all the channels. Any spare bandwidth is available for 
any channel to use. 

The difference can be seen by simply looking at the amount of total bandwidth 
necessary to support the traffic being sent. Both diagrams show the same amount of 
bandwidth for each traffic type. In the case of the TDM, a larger amount of total 
bandwidth is needed to support all three traffic types, and the spare bandwidth (shown 
in white) is not available for use. In the case of ATM, the overall amount of bandwidth 
needed is smaller, and the spare bandwidth is available for other channels to use. 
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Figure 9.6 Statistical Multiplexing with ATM 


9.2 Voice and Telephony Over ATM (VTOA) 

At the time of writing of this booklet, there is a lot of activity within the ATM Forum 
for the development of standards for Voice and Telephony Over ATM (VTOA). Due to 
the current state of flux in these standards, we have resisted from providing too much 
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detail here. Instead, we have provided fairly generic descriptions of voice support over 
ATM along with a look at some of the issues involved as well as providing a summary 
of the key standards. 

Techniques for VTOA include the support of a complete structured PBX data stream 
(e.g. DS1/E1) as well as the support of a single or multiple voice channels (sometimes 
referred to as trunking) over a single Virtual Channel Connection (VCC). In the former 
case, circuit emulation techniques are typically used. In the latter case voice samples, 
whether they be PCM or compressed speech samples, need to be inserted into ATM 
cells using an ATM Adaptation Layer. The choice of AAL depends upon the specific 
application in use, and a number of different AALs are being proposed including 
AAL1, AAL5 and AAL2. A summary of the currently defined standards is as follows: 

AF-SAA-0032.000 - "Circuit Emulation Service Interoperability Specification" - 

Supports structured (fractional) and unstructured DS-1 and El CBR services over 
AAL1. 

AF-VTOA-0078.000 - "Circuit Emulation Service Interoperability Specification 
Version 2.0" - Defines circuit emulation services using AAL1 for both structured and 
unstructured services. The structured services are modelled on fractional DS1/E1/J2 
circuits and allow one or many (as appropriate) voice channels to be carried on a single 
VCC. This is in contrast to the unstructured services which define transparent trans¬ 
mission of the data streams and is modelled on regular leased lines 

AF-VTOA-0083.000 - "Voice and Telephony Over ATM to the Desktop" - This 
specification defines the use of AAL5 for voice support over ATM to the desktop. It 
provides the ability to support switched connections with one 64kbit/s CBR voice 
channel per VCC. It also defines interworking support with Primary Rate (PRI) and 
Basic Rate (BRI) services and interworking with private and public network interfaces. 

AF-VTOA-0085.000 - "Dynamic Bandwidth Utilisation - in 64kbit/s Timeslot 
Trunking Over ATM - Using CES" - Defines how voice channels from a digital voice 
interface may be carried only when they are active thus providing dynamic bandwidth 
utilisation. The method for detecting voice activity is beyond the scope of the document. 

AF-VTOA-0089.000 - "ATM Trunking Using AAL1 for Narrowband Services 
Version 1.0" - Effectively an extension to the capabilities of AF-VTOA-0078.000 and 
providing much more flexibility in the way that voice channels may be carried across 
an ATM network. Additional capabilities include call-by-call routing, bandwidth on 
demand, bandwidth sharing and the support of DS1/E1 with signalling. 

Further to these specifications, a new AAL, AAL2, is being defined for the support of 
low and variable bit rate trunking applications where single or multiple voice channels 
are carried in a single VCC. 
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9.2.1 Voice Sample Cellification 

To carry voice over ATM requires a block of voice samples to be inserted into the 
payload of the ATM cell. 

Figure 9.7 shows the principle behind this cellification process. Before a cell is trans¬ 
mitted off into the network it first needs to be filled with voice samples. If these are 
PCM samples from a single voice channel then they will arrive from PBX1 every 
125ps. If the cell payload is 47 bytes long (see example in Section 9.2.2) it will take 47 
x 125(is (5.875ms) before the cell is full and can be transmitted into the network. This 
demonstrates one of the penalties to be paid when using voice over ATM (or indeed any 
cell/ffame based system) i.e. delay. However, 5.875ms delay is small and, in practice, 
is insignificant as far as voice is concerned. 



Figure 9.7 Voice Sample Cellification 


At the exit point of the network, the cell enters the destination ATM multiplexer where 
the contents of the cell are emptied and passed onto the interface for onward transmis¬ 
sion to PBX2. 

Due to the nature of a cell based network, a certain amount of delay may be imposed 
on the cells transmitted from one end of the network to the other. Furthermore, due to 
variations in the loading on various cell switches within the network, this delay may 
vary. This is known as Cell Delay Variation (CDV). To overcome this potential problem 
of running out of cells at the destination multiplexer due to this CDV, a buffer must be 
introduced at the receive end of the connection (see Figure 9.7). Due to this buffer, 
additional delay will be incurred. 

We saw in section 6 on enterprise networks, that to save bandwidth, speech compression 
is often performed. The general effect of this is to reduce the number of bits with which 
to fill the cell at the sending end, and this increases the cellification delay. For example, 
if we went to the extent of compressing the speech from 64kbit/s to, say, 16kbit/s 
ADPCM the cellification delay would rise from 5.875ms to 23.5ms, a non-trivial amount. 
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There are a couple of methods that can be used to overcome this issue of delay. Some 
have suggested partially filling the cells before transmitting them, although doing this 
counteracts the benefits of compressing the speech in the first place. The other 
technique is to multiplex multiple voice channels within one VCC and this is currently 
being investigated by the ATM Forum to be supported in AAL2. 

9.2.2 Speech Activity Detection 

Speech Activity Detection (SAD), also known as silence suppression, is an important 
function performed by some ATM/cell based voice systems. It allows valuable 
bandwidth to be saved by not transmitting cells during periods of silence. The 
bandwidth savings can be significant since, in a typical conversation, silence accounts 
for up to 60% of the speech in each direction. However, bandwidth savings should not 
come at the expense of voice quality. If SAD is not performed properly, it can be a 
potential source of voice signal impairment 

There are four significant aspects of SAD that can affect speech quality: 

Attack time - This is the time taken to detect the start of a talk spurt (or speech burst) 
after a period of silence. A very long attack time causes the front end of the talk spurt 
to be clipped. Therefore, the interpolation implementation must respond very quickly 
to the start of a talk spurt. 

Speech threshold - This is the level above which the signal is considered to be speech 
and below which the signal is considered to be silence. Traditional silence detection 
compares the energy of the speech signal to a pre-selected energy threshold level. 
Typically, speech is detected if the signal stays above the threshold for more than a 
predetermined period of time; silence is detected if the signal is below the threshold for 
more than a predetermined period of time (called the hangtime). Such an approach does 
not take into account any varying and constant background noise. Consequently, the 
approach could detect real speech periods as silence (when the background noise is 
low) and real silence (when the background noise is high). A more accurate speech 
detection method adapts the threshold relative to the background noise to prevent 
premature speech clipping. 

Hangtime - This is the time taken to detect the end of a talk spurt (the start of a silence 
period). If the hangtime is set very short in an attempt to maximise bandwidth savings, 
inter-syllable pauses can be misconstrued as silence periods. If the hangtime is set very 
long, entire silence periods can be missed. The optimal hangtime is one which strikes 
a balance between speech quality and bandwidth savings. 

Comfort Noise - A potential drawback with SAD is that during periods of silence, 
when no cells are being transmitted, the receiving end will hear absolute silence, not 
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even background noise. Many systems overcome this by injecting what is known as 
“comfort noise” into the voice path at the receiving end during these periods. The level 
of noise injected will be set to be similar to the background noise of the sending end. 

9.3 PBX Synchronisation Across an ATM Network 

When connecting PBXs together using digital interfaces whether directly, via a TDM 
network or via an ATM network, the PBXs need to be synchronised to one another. By 
their very nature, ATM networks may or may not operate in a synchronous manner 
internally and, indeed, may not be synchronised with the attached PBXs. Therefore, a 
method is required to maintain synchronisation on an end-to-end basis. 

The recommended method for PBX synchronisation is to derive timing for the PBXs 
at each end of a link from a common primary reference source. However, where this is 
not possible, ITU-T 1.363 suggests two methods for providing end-to-end synchronisa¬ 
tion when doing circuit emulation with AAL1. The first of these is called Synchronous 
Residual Time Stamp (SRTS) and the second the Adaptive Clock Method. 

9.3.1 Synchronous Residual Time Stamp (SRTS) 

In principle, the SRTS method conveys information from one end of the connection to 
the other about the frequency difference between a common reference clock, such as 
derived from SDH/SONET, and the service clock received from the PBX. For this 
method to work, it is a requirement that the same derived network clock is available at 
both ends as would be the case with transmission via SDH or SONET or if the ATM 
multiplexers were connected via a master/slave clocking relationship. 



PBX 1 _ _ PBX 2 



Common reference 
clock source 
(e.g. from SDH) 

Figure 9.8 Synchronous Residual Time Stamp (SRTS) 
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The principle of clock transfer is basically simple and is demonstrated in Figure 9.8. 
The service clock frequency from PBX 1 is divided by a fixed value to produce a signal 
with a period T. The number of cycles of the common reference clock occurring in 
period T is counted and this number is transmitted to the destination as the Residual 
Time Stamp (RTS) using the CSI bit in the AAL1 header. The receiver can then recon¬ 
struct the service clock from the RTS and the common reference clock and use this to 
drive the bit stream into PBX 2. 

A more detailed description of SRTS can be found in ITU-T 1.363. 

9.3.2 Adaptive Clock Recovery (ACR) 

A less common approach to end-to-end synchronisation is Adaptive Clock Recovery 
(ACR). Figure 9.9 shows the principles of operation of ACR. At the destination end of 
the connection over the ATM network, the received information is written into a buffer 
whenever a cell arrives. Due to the asynchronous nature of ATM and Cell Delay 
Variation (CDV) in the network, the buffer fill rate will not be consistent. However, the 
bit stream that is transmitted to the attached PBX is controlled by a local clock. To 
synchronise this clock to the speed of the far end PBX interface, the local clock 
frequency is controlled by the fill level of the buffer. If the buffer starts to empty, the 
clock is running too fast and a phase locked loop mechanism slows the clock down 
until the buffer can maintain its mid-point fill level. Conversely, if the buffer starts to 
fill, the clock is running too slowly and is sped up. 


Buffer 


Cells received 
from network 



If one or more of the cells is lost on route from source to destination, the interface can 
identify this through the use of the sequence number or simply by use of a timer. Since 
a synchronised clock still needs to be generated out to the interface, a dummy cell is 
inserted into the buffer. 
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9.3.3 Independent Timing 

Another alternative method of providing timing for each end of an ATM connection is 
to derive it from an independent clock source at each end of the connection. This is 
currently considered as a feasible mechanism for voice to the desktop where it is likely 
that a telephone will connect into a Personal Computer (PC) to provide the service. The 
independent clock source could be the PC’s internal clock, or another source located on 
the telephone interface card. One potential problem is that these clock sources are 
inherently inaccurate and clock slips could potentially occur. However, there are many 
methods that can be used to minimise the effect that this has on voice quality. For 
example, for speech with silence suppression, intelligent buffer management can be 
used at the network egress point to ensure that any clipping or clicks will not be heard. 
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10 Voice Over Frame Relay 

The use of frame relay has, over the last few years, grown at an explosive rate and 
continues to do so today. While it has not traditionally been seen as a suitable technol¬ 
ogy for carrying voice, developments in digital processing and the resulting newer 
products are changing that view. 

This section begins with a brief introduction to frame relay, followed by a look at how 
voice is supported along with some of the issues involved. 

10.1 Introduction to Frame Relay 

Frame relay is a communications standard that was originally defined for use over the 
ISDN (Integrated Services Digital Network) although has since found wide acceptance 
for the transport of data such as LAN traffic in both private and public networks. 

In 1991, the Frame Relay Forum was established in order to promote the interoper¬ 
ability of products and services from different vendors. The Frame Relay Forum 
defines Implementation Agreements which represent an agreement by all members of 
the frame relay community as to the Specific manner in which standards will be 
applied. As with ATM Forum standards, much reference is made to existing ITU-T 
Recommendations. 

Frame relay developed from X.25 but offers much greater efficiencies and speed of 
operation, albeit at the expense of error protection. However, frame relay is assumed to 
operate over low error rate digital lines thus removing the need for error protection 
anyway. If frames are corrupted in a network, they are discarded, and it is the respon¬ 
sibility of the end devices to identify the loss and initiate recovery, for example, by 


Address 


1 Flag 1 


Information Field FCS Flag 



DLCI (6 bits) C/R 

0 

DLCI (4 bits) FN BN DE 1 


Data Link Connection Identifier (DLCI) - Used for the link addressing function. 
Command/Response (C/R) - Determines if the frame is a Command or Response. 
Forward Explicit Congestion Indication (FN) - Indicates congestion to receiver. 
Backward Explicit Congestion Indication (BN) - Indicates congestion to sender. 
Discard Eligibility (DE) - Identifies frame to be discarded in preference to others. 
Frame Check Sequence (FCS) - Used to identify errors in the frame. 

Figure 10.1 Frame Relay Frame 
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re-transmitting the frame (if possible). Frame relay operates by taking information from 
the source e.g. LAN data and packaging it up into a frame along with a few bytes of 
overhead. The structure commonly used is defined in ITU-T Recommendation Q.922 
Annex A and is shown in Figure 10.1. Two other formats using 3 and 4 byte addresses 
are also defined in Q.922 but they are not commonly used. 

The Frame Relay Forum defines an Information Field size of at least 1600 bytes (to 
cope with most LAN requirements), although sizes of less than or greater than this may 
be agreed to between the network and the user. In practice. Information Field sizes of 
up to 4096 bytes are not uncommon. 

Frame relay is a connection oriented protocol i.e. a path must be set up through a 
network from source to destination before data frames can be sent. Both Permanent 
Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs) are supported allowing 
multiple Virtual Circuits (VCs) to be carried on the same physical link. The DLCI field 
is then used by the end devices on a link to differentiate between different VCs and 
route the frames to the appropriate destination. 

Frame relay is a very efficient method of communication over a range of speeds up to 
and including E3 (34.368Mbit/s) and DS-3 (45.736Mbit/s). The beauty of frame relay 
comes from its ability to statistically multiplex traffic from different sources. In other 
words, bandwidth on a frame relay link is only used by a source when that source has 
traffic to send. If a particular source has no traffic to send, then the bandwidth on the 
link is potentially free for other sources to use. 


The rapid growth in frame relay usage over the last few years has been driven mostly 
by the interconnection of LANs (Local Area Networks). A typical arrangement is 
shown in Figure 10.2 where multiple LAN routers need to be connected together. Only 



LAN 


Figure 10.2 Typical Application for Frame Relay 
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one physical link is needed between each router and the network, with different DLCIs 
being used to differentiate one VC from another. It should be noted that the number 
used for a particular DLCI only has local significance on a particular link. 

10.2 Voice Over Frame Relay (VoFR) 

While LAN interconnection is the dominant application today, users are now looking 
to carry other types of traffic, including voice, over frame relay networks. Historically, 
voice support over frame relay was not deemed to be practical due to the potential 
delays that the networks could impose. However, frame relay networks have tended to 
evolve utilising high speed switching technologies such as ATM which will readily 
support delay sensitive applications such as voice. As a result, Voice over Frame Relay 
(VoFR) has become a reality, indeed, the Frame Relay Forum is currently in the process 
of ratifying standards for its support. Meanwhile, a large number of vendors have 
already developed products (sometimes known as Frame Relay Access Devices 
(FRADs) for VoFR, albeit using proprietary methods of carrying voice samples within 
a frame relay frame. A typical view of a network using FRADs is shown in Figure 10.3. 



FRAD 


Frame Relay 
Network 


FRAD 


Device 


VC = Virtual Circuit 
FRAD = Frame Relay Access 


FRAD 


PBX 


Figure 10.3 Typical Application using FRADs 


In this case, the FRADs are taking input from a number of different voice and data 
devices and multiplexing them across the links into the frame relay network where a 
number of Virtual Circuits (VCs) are set up between FRADs. Please note that real 
FRAD products will often provide a wider range of interfaces than shown here. 
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10.2.1 Delay on Frame Relay Networks 

One key aspect of supporting voice across a network is that it requires a fixed and 
minimal delay. While today’s frame relay networks offer fairly consistent and low 
delay, they do however add delay and, possibly more importantly, they add variation in 
delay from one frame to the next (known as jitter). Since voice requires a constant flow 
of frames, a mechanism is needed to overcome this jitter. This is usually in the form of 
a de-jitter buffer which stores up frames at the input to the FRAD thus effectively 
smoothing out the arrival of frames. 

Frame relay is designed to multiplex data from many sources onto a single link with 
frames from different sources being multiplexed on a first-come-first-served basis. In 
the case of voice frames, this is not sufficiently good practice due to the possible delay 
and delay variation caused by buffering them up for transmission. As a result, voice 
frames are usually given a higher priority than frames carrying other less delay 
sensitive traffic such as most LAN data. For example, if a LAN frame is queued up for 
transmission at the output of a FRAD, and a voice frame then arrives from the voice 
interface, the voice frame will “jump the queue” and be transmitted first. However, if 
the LAN frame is already being transmitted when the voice frame arrives, the voice 
frame will have to wait until the LAN frame had been completely sent. If the LAN 
frame is large, which is perfectly feasible, then the voice frame could be delayed for 
quite a long time. 

To alleviate this problem, many of the existing FRAD products will fragment large 
frames into a number of smaller ones thus keeping this delay to a minimum, typically 
in the range 5 to 10ms. These techniques are currently proprietary to each product 
vendor, although the Frame Relay Forum is currently working on a standard method for 
fragmentation so that dissimilar products can inter-operate. 

10.2.2 VoFR Standards 

As highlighted earlier, most products supporting VoFR today do so in a proprietary 
manner and will only support operation between two similar devices. 

At the time of writing of this booklet, the Frame Relay Forum has just completed and 
approved a new Implementation Agreement (LA.), FRF. 11 [29] for the standardised 
support of voice over frame relay (VoFR). FRF. 11 describes methods for the following: 

- The transport of compressed voice within the payload of a frame relay frame 

- The support of a diverse set of voice compression algorithms 

- The effective utilisation of low-bit rate frame relay connections 

- The multiplexing of up to 255 sub-channels on a single frame relay DLCI 
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- The support of multiple voice payloads on the same frame or different sub¬ 
channels within a single frame 

- The support of data sub-channels on a multiplexed frame relay DLCI 

Figure 10.4 gives an example that demonstrates how FRF. 11 describes the support of 
voice over frame relay. In this example, a single frame is shown carrying two separate 
voice channels. The frame relay header represents the normal header information 
(DLCI etc.) as shown in Figure 10.4. LI is the Length Indicator bit and is used to 
indicate whether or not a 1 octet length byte is present. It is clear (set to 0) if the channel 
is the only channel or the last channel in the frame, in which case the length byte is 
absent. The LI bits of all sub-frames preceding the last one are set to 1. El identifies the 
length of the channel ID as being either 6 or 8 bits and allows either 63 or 255 channels 
to be supported in the frame. If set to 0 then it also implies that the payload will be 
either Embedded ADPCM (G.727) or CS-ACELP (G.729) speech depending upon 
whether Class 1 or Class 2 compliance is required. Class 1 refers to support capabili¬ 
ties for high bit-rate frame relay interfaces and Class 2 for low bit-rate interfaces. 
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Figure 10.4 VoFR Frame 


The payload type identifies what is actually being carried in the payload i.e. whether it 
is speech, signalling, fax relay data or a silence information descriptor. 

FRF. 11 provides for the support of a wide range of speech coding schemes as 
summarised in Figure 10.5. Included are details of the coding rates, the number of bytes 
carried for one voice channel in each sub-frame and the associated packetisation delay. 
Many of the coding types allow for multiple blocks to be carried in the same sub-frame. 
M is referred to as the packing factor and can be set over a range dependent upon which 
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coding scheme is being used. 

In addition to supporting a wide range of speech compression techniques, FRF. 11 also 


Coding Type 
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Bit Rate 
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Delay 

PCM 
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40 *M 
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G.726 

40kbit/s 

25 * M 
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20 
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10 *M 
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Figure 10.5 VoFR Frame Details 


describes the support of other voice related services including signalling information and 
encoded fax traffic. It describes how signalling can be carried either as Channel Associated 
Signalling (CAS), Common Channel Signalling (CCS) or as in-band dialled digits. 

10.3 Benefits and Issues of VoFR 

10.3.1 Benefits 

Frame relay networks continue to grow at an explosive rate, and the fundamental 
ability to integrate voice into the, traditionally, data only enviromnent will bring great 
benefits to network managers by minimising the costs of consolidating voice and data. 

As with ATM, a wealth of other benefits also exist. Firstly, frame relay offers statisti¬ 
cal multiplexing of traffic thus making optimum use of the bandwidth available. 
Speech compression further reduces the bandwidth needed on links (see Section 5), 
although care needs to be taken when supporting non-voice traffic such as modems or 
facsimiles. To further reduce the bandwidth taken, frame relay lends itself very nicely 
to techniques such as silence suppression which typically will result in a further 50% 
saving of network bandwidth (see Section 9.2.4 on SAD on ATM). 
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10.3.2 Issues 

Probably the most significant issue of supporting voice over frame relay is the delay 
imposed as discussed in Section 10.2.1. This would particularly be an issue in a 
network where multiple hops are involved. The delays even on a single hop are likely 
to be high, necessitating the use of echo cancellation techniques as discussed in 
Section 6. 

Many products used within frame relay backbone networks support voice through a 
prioritisation process similar to that described in Section 10.2.1. However, many of 
these products are themselves cell based and expect voice to be carried in these "small" 
cells rather than large frames. In this way, they can reasonably use the prioritisation 
process without significantly affecting the frames that are being held back as lower 
priority. If the voice frame is large as allowed by the standard, by giving it a high 
priority may adversely affect the lower priority frames. As a result, wherever possible, 
frames should be kept relatively small, say, below 100 bytes. 

Although not discussed in the context of frame relay, wherever voice is supported on 
digital interfaces, methods for enabling synchronisation between PBXs will need to be 
provided. This is an area which still requires to be standardised. 

Speech compression, which is likely to be used extensively in applications of voice 
over frame relay creates its own issues as discussed in Section 5.7. 
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11 Voice Over IP 

Internet Protocol (IP) networks have practically become the corporate standard for 
LAN and WAN data traffic with users ranging from small home office operators to 
large multinational organisations. In fact, the growth in the use of IP has been so great 
over the last few years that a new version of IP, known as IP version 6 (IPv6) or IP Next 
Generation (IPng) [22], has been defined to deal with a number of issues existing with 
the present version of IP, IP version 4. 

As a result of its popularity, IP has developed to become probably the most flexible 
networking protocol in use today. IP networks run under the most widely used network 
operating systems, they are highly scalable and they work well with routers, making 
them ideal for transmitting data over a wide area network. 

Today, the demand for new applications including voice and fax over IP is growing, 
both in corporate IP environments as well as for Small Office Home Office (SOHO) 
applications. 

Probably the best known IP network in existence today is the Internet. While a lot has 
been said about the support of "voice over the Internet", performance issues including 
large transmission delays and poor voice quality have prevented the Internet from being 
used extensively for corporate voice traffic. Part of the problem has been the inability to 
support guaranteed levels of performance. However, corporate and other private IP 
networks today can be more effectively managed to handle real-time network traffic 
such as voice, through mechanisms such as ongoing detailed network engineering that 
allows performance levels to be defined. 

11.1 What is IP 

IP is a networking protocol which was originally designed primarily to support data. 
Today IP version 4 is the most common version as described in RFC 791 [23]. Other 
protocols commonly used with IP include the Transmission Control Protocol (TCP) 
[24] and the User Datagram Protocol (UDP) [25]. TCP is designed to provide a guar¬ 
anteed delivery service for data packets over IP, while UDP provides a non-guaranteed 
delivery service. However, neither of these protocols guarantee support of real-time 
applications such as voice. 

In order to support real-time applications, other protocols have been developed to run 
over IP networks. These include the Real Time Protocol (RTP) [26] and the Resource 
reservation Protocol (RSVP) (currently a draft RFC). 

Real Time Protocol (RTP) - Defined in RFC 1889, RTP provides an end-to-end 
delivery service for real-time traffic applications including voice and video over 
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unicast (point-to-point) or multicast (point-to-multipoint) connections. It provides 
services including payload type identification, sequence numbering, time-stamping and 
delivery monitoring. In conjunction with RTP is RFC 1890 [27] which describes how 
audio and video may be carried within RTR 

RTP was developed to operate independently of the underlying transport and network 
layers and while it is common to run it on top of UDP and IP, it can be used with other 
protocols such as ATM or IPX if required. Integral to RTP is the Real-time Transport 
Control Protocol (RTCP) which is used, amongst other things, to provide feedback on 
the quality of the received data on a connection. 

Reservation Protocol (RSVP) - At the time of writing of this booklet, RSVP is a draft 
RFC and has not yet been allocated a number. The basic idea of RSVP is to reserve 
network bandwidth for a flow of information so that a specified Quality of Service 
(QoS) can be given to that information flow. The general process behind RSVP is to 
use a "flow descriptor" to request a particular QoS from the network so that when the 
real information is transmitted, it is given the necessary resources in the network to 
guarantee perfonnance. In many respects this process resembles that used for defining 
a traffic contract in ATM and, in essence, turns the connectionless nature (best-try) of 
IP into a connection oriented (reliable) service. It should be recognized that RSVP is 
not expect to reach market readiness for the next 2-5 years. 

11.1.1 How Voice Over IP Works 

Figure 11.4 shows a possible configuration of a network supporting voice over IP. The 
actual implementation will be vendor specific, however this shows one possible solution. 
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To place a call from one telephone to another, a user dials the number corresponding to 
the destination phone. The local PBX interprets the digits and routes the call to the 
locally attached Voice over IP Gateway on either an analogue or a digital interface card. 
The gateway maps the destination telephone number to the IP address of the gateway 
at the location of the destination phone. The source gateway then establishes a route to 
the destination. If a protocol such as RSVP is available, then it is used to request allo¬ 
cation of bandwidth in the network. The call is connected and proceeds with IP packets 
carrying digitised voice samples being transmitted between the two ends. 

11.1.2 Benefits and Issues of Voice Over IP 

As with voice integration into other packet (or frame or cell) based enterprise networks, 
benefits of significant bandwidth savings can be derived using such techniques as 
speech compression and silence suppression. 

However, as it stands today, voice over IP is still in its infancy and many issues exist 
which need to be understood. The main issues are to do with delay which will comprise 
voice coding delays, packetisation delays, delays across the wide area network, de- 
packetisation and anti-jitter delays. 

As discussed earlier, IP does not provide any quality of service guarantees, and other 
mechanisms are required to provide them. RSVP has been defined in order that 
bandwidth can be allocated to a particular connection via an IP wide area network. 
Today, however, most routers do not yet support RSVP and, where it is supported, it 
places a considerable processing burden on the routers. Meanwhile, networks such as 
the Internet will impose delays typically in the order of several seconds. 

11.1.3 Standards 

Standards for Voice over IP are looked after by the Voice Over IP Forum, a group of 
Internet telephony vendors organised under the auspices of the International 
Multimedia Teleconferencing Consortium (IMTC). 

VoIP standards are based upon ITU-T Recommendation H.323, "Visual Telephone 
Systems and Equipment for Local Area Networks which Provide a Non-Guaranteed 
Quality of Service". This recommendation is based of the Real-Time Protocol/Control 
Protocol (RTP/RTCP) as described briefly in section 6.3.1. H.323 defines the support 
of five encoding algorithms: G.711, G.722, G.728, G.723.1 and G.729 with G.723.1 
having been chosen as the default for Internet telephony applications. 
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12 Voice Switching in the Enterprise Network 

Today, organisations are under mounting pressure to provide increased levels of 
connectivity and greater bandwidth availability to geographically disperse user groups 
throughout the business. At the same time, they must consider network consolidation 
strategies to control and even reduce overall networking costs. Although voice traffic 
predominates on today's networks, sporadic data traffic, on-demand video, and image 
traffic is making the network environment increasingly complex. Consequently, users 
are becoming more conscious of the bandwidth consumption of their applications, and 
are looking for ways to reduce bandwidth costs. 

As a result, two objectives have risen to the forefront of network purchase decisions: 

1. Realising overall network cost savings. 

2. Maintaining or enhancing current levels of user-perceived quality (especially 
with regard to voice services). 

Cell-switching delivers the promise of allowing a variety of network applications - such 
as voice, video, data, and image - to efficiently share expensive bandwidth resources, 
while simultaneously delivering service quality that meets or exceeds user requirements. 

Cell switching is of significant value to voice transport. In section 9.2 we saw that, by 
using Speech Activity Detection (SAD), a cell based system can selectively transmit 
cells only when they contain useful digitised voice information. This, combined with 
speech compression, provides significant savings on bandwidth used, allowing more 
channels to share the costly inter-site trunk circuits. Figure 12.1 gives a guide as to the 
number of voice circuits that should be able to simultaneously share a 2Mbit/s trunk 



Comp. = Compression 

Figure 12.1 Number of Voice Circuits on a 2Mbit/s Link With and Without SAD 
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with and without SAD, and assuming that the voice traffic occupies about 80% of the 
2Mbit/s link capacity. Furthermore, when a voice circuit is inactive, the bandwidth 
allocated can be made available for other traffic. 


12.1 The Evolution of Voice Networks 


In the 1980s, intelligent corporate PBX networks were being built using digital Tl/El 
leased line connections as shown in Figure 3.2. 

Since then, TDM multiplexer solutions have been adopted by many corporations to reduce 
bandwidth costs by integrating their voice traffic with other traffic such as data and video. 
Flowever, the designs of PBX networks have remained largely unchanged, albeit with the 
PBXs connected together via these TDM networks. Figures 12.2 and 12.3 show two 
network scenarios used for connecting PBXs together via Wide Area Networks. 

Figure 12.2 shows the configuration used when running Channel Associated Signalling 
(CAS - see Section 7.2) on the PBXs. In this case, each PBX is connected to a multi¬ 
plexer via one or more 1.544 Mbit/s links, the number being dictated by the total 
number of voice circuits required. By using CAS, the multiplexer is able to interpret 
the signalling bits for each channel and route them on a per channel basis along with 
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the channel itself. In this way, one PBX digital trunk can serve multiple destinations. 
Also, should a channel connection fail within the network, the multiplexers can 
indicate this back to the relevant PBXs with a Backward Busy signal so that it does not 
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use that particular channel. The multiplexers also offer other benefits including the 
ability to compress speech, support automatic channel re-routing in the event of failure, 
and so on. 

There are also a number of drawbacks with this approach, all centred around the fact 
that the switching is done in the PBXs. Firstly, a call placed from Telephone A to 
Telephone B will need to be routed from PBX 1, via PBX 4 and onto PBX 5. If speech 
compression is used, multiple compressions and decompressions will occur, resulting 
in greater distortion of the speech. Also, two timeslots are used on the link into PBX 4 
which is wasteful in terms of bandwidth. 

Figure 12.3 shows the configuration used when running Common Channel Signalling 
(CCS - see Section 7.2.2) on the PBXs. With CCS, it is far more complicated for the 
multiplexer to interpret the signalling from the PBX than with CAS. Therefore, to 
create paths between, say, PBX 1 and PBXs 2 and 4, separate interfaces are required on 
PBX 1. The number of links required at PBX 1 is dictated by the number of other PBXs 
connected to it and is independent of how few channels are actually being used. 

Again, the benefits derived using this approach include the ability to compress speech and 
support automatic channel re-routing as well as the added benefits of using CCS itself. 

The drawbacks are the same as with CAS with two notable additions: Firstly, the 
number of interfaces on the PBXs and the multiplexers is increased when using CAS. 
Secondly, if a channel connection should fail within the multiplexer network, the multi¬ 
plexers have no way of signalling this to the PBXs on a per channel basis. This is 
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Figure 12.3 PBX Network Overlaid Onto Multiplexers Using CCS 
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because the multiplexers would need to be able to generate CCS messages themselves. 
Instead, the multiplexer will need to set a Remote Alann Indication (Yellow alarm) to 
the PBXs on the interfaces that carry the failed channel. The PBX sees this as a trunk 
level alarm and busies out the whole trunk. 


12.2 What is Voice Switching 

Today's view of voice networks suggests that all PBXs should be able to connect to the 
corporate "enterprise" network and all PBXs will be able to establish a direct connec¬ 
tion to any other PBX. Put more simply, the network would act like a large transit (or 
tandem) PBX (see Figure 12.4). 
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Figure 12.4 Enterprise Network Voice Switching 


This requires that the network can interpret the signalling from the PBX, including such 
information as the called number, and then, based upon this information, make an intel¬ 
ligent routing decision. For example, if we consider a call placed from Telephone A to 
Telephone B in Figure 12.4, PBX 1 routes the call into the enterprise network. But now, 
with voice switching, the enterprise network inspects the dialled number and routes the 
connection to the appropriate destination. The call is therefore routed directly to PBX 
5 rather than needing to be sent via a tandem PBX. 

Voice switching can be supported with CAS or CCS signalling, although more func¬ 
tionality can be achieved with CCS due to the additional information carried in the call 
setup messages. Of course, the network needs to be able to handle the specific protocols 
used e.g. NIS, ETSI or QSIQ etc. 
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It is envisaged that the PBX will still need to connect to other types of networks, such 
as the PSTN or Virtual Private Networks, so that calls can be routed over a number of 
different paths. This allows the network to be more resilient to backbone failures, as 
well as allowing overflow of peak period traffic onto cheaper networks. 

12.3 Why Perform Voice Switching 

Voice switching in the enterprise network brings many benefits: 

Reduction in PBX hardware - Investment in PBX and backbone network hardware 
can be reduced if the transit capability is undertaken by the wide area network. The 
number of digital PBX interfaces required is based on traffic volumes rather than on 
the number of neighbouring PBXs. 

Maintenance of end-to-end voice call quality - Many users of PBX networks have 
had bad experiences with speech compression in their networks. The obvious 
bandwidth savings achieved through compression can be offset by the problems asso¬ 
ciated with trying to maintain voice quality in a multi-hop PBX network. A large 
majority of corporations using multiplexers to support their PBX networks use either 
no compression or standard 32 kbit/s ADPCM designed specifically to operate in a 
multi-hop PBX environment. By following this and other criteria (e.g. limiting end-to- 
end delay), voice quality can be maintained across the network. The use of more exotic 
(proprietary) protocols, with large delays, has resulted in poor or inconsistent end-to- 
end voice quality when used in anything other than point-to-point voice environments. 

Therefore, the ability to limit the number of speech compressions/decompressions to 
one, has risen as one of the prime drivers for voice switching in an enterprise network. 
That is, since the wide-area network acts like a tandem node in a star network, only one 
compression/decompression is encountered per call. This is also a regulatory require¬ 
ment in some countries, such as Germany, for calls breaking out to the PSTN. 

Individual channel busy-back - Most implementations of TDM multiplexers can only 
indicate routing problems to a PBX by busying out all channels on the El /T1 primary 
rate interface via the RAJ (yellow alarm). This is because the multiplexing equipment 
does not provide any intelligent signalling on the D-channel and must rely on physical 
level attributes to provide feedback to the PBX. This approach is inefficient in conges¬ 
tion or failure scenarios, as all subsequent calls must then be re-routed even if only a 
single PBX trunk (time slot) cannot be routed by the network. 
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For the network to be effective as a transit PBX, it must work intelligently with the D- 
channel call control signalling. If a call cannot be routed, due to unavailable bandwidth 
for example, then the local network node needs to signal the originating PBX on the D- 
channel. The PBX needs to be informed that the individual call cannot be routed by the 
network and should use an alternate route (for example, the PSTN). 

Voice/data discrimination - Currently, for voice and data to operate in an integrated 
PBX network across multiplexers that support compression, the data channels must be 
segregated from the voice in order to avoid compression. With CCS it is common that 
at call setup, the type of call is identified in the call setup message (see Section 7.2.2). 
Since the network is interpreting this signalling, voice and data can be discriminated 
between and compression only used where appropriate. 

Bandwidth savings - In traditional PBX networks operating over multiplexer 
networks, calls that route through tandem PBXs will consume more network bandwidth 
than those that do not. This is because bandwidth is consumed at the input and output 
of the tandem PBX and often demands less efficient network routing paths. In extreme 
cases, the network design could allow many multiples of the original call bandwidth to 
be consumed by a multi-hop call. Often this use of bandwidth is unavoidable. Some 
network managers do not fully appreciate the cost implications. With voice switching 
in the enterprise network, each call would be routed over the most direct path at the 
time the call was made resulting in large savings in bandwidth. 
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Appendix A - Company and Product Overview 
Nortel's History 

Having patented the telephone in the USA in 1876, Alexander Graham Bell did the 
same in Canada in 1877 where 75 percent of the Canadian Patent was assigned to his 
father, Melville. 

Within two years, Melville Bell had sold his share to National Bell, the predecessor of 
AT&T. In 1880, the Bell Telephone Company of Canada was formed. The manufactur¬ 
ing branch flourished and in 1895 was incorporated as a separate company called 
Northern Electric and Manufacturing Company Limited. 

In 1899 The Bell Telephone Company of Canada purchased a Montreal wire and cable 
factory which later would be called the Imperial Wire and Cable Company Limited. 

In 1914 the two companies amalgamated to form The Northern Electric Company 
Limited. Forty four percent was owned by Western Electric, the manufacturing 
subsidiary of AT&T Company of the United States, and the remainder by Bell Canada. 

The Western Electric involvement continued until the Consent Decree of 1956 when, 
Western Electric terminated its patent and licensing relationship with Northern Electric. 
Northern Electric began to achieve technical independence in 1957 by creating its own 
research and development facilities in Belleville, Ontario, and in 1959, established 
Northern Electric Research and Development Laboratories in Ottawa, Ontario. At the 
same time, Bell Canada began stepping up its own development activities. 

In 1971, Northern Electric and Bell Canada merged their R&D activities to form Bell 
Northern Research (BNR). In the early seventies BNR began developing what it called 
the "E-thing", an electronic switching system. By late 1972, Northern Electric had its 
first electronic switch on the market, called the SGI (but also known as PULSE) private 
branch exchange (PBX). Within 3 years, some 6,000 SGI systems had been sold. 

The real story behind the E-thing is its evolution to an all digital switch called the SL-1. 
The SL-1 design was so successful, that it was logical to extend the new powerful digital 
technology to central office (CO), or public exchanges. BNR developed the DMS-10 for 
small COs in 1977 followed, two years later, by the DMS-100 digital switch for large 
central offices. 

In 1976 Northern Electric changed its name to Northern Telecom Limited. Since then, 
Northern Telecom has gone from strength to strength, developing new products, and 
breaking into new markets, as well as making existing systems more reliable, powerful 
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and cost-effective. More recently, the Enterprise Networking portfolio of products has 
been developed to address the emerging and rapidly growing broadband multimedia 
markets. 

In 1995, Northern Telecom unveiled a new corporate logo. This would be used globally 
as the company's unique corporate signature. The name Nortel, which the corporation's 
subsidiaries and joint ventures around the world already used, is a shortened fonn of 
Northern Telecom. The legal name of the corporation has, however, remained Northern 
Telecom Limited. 

Nortel 

As a leading global provider of digital networks, Nortel delivers solutions for wireless, 
broadband, enterprise and carrier networks. Nortel works with customers world-wide 
to design, build and integrate digital networks for communications, information, enter¬ 
tainment, education and business. According to Dataquest (Wide Area Network 
Equipment Market Share and Forecast Report), Nortel is now the number one WAN 
equipment vendor world-wide. The latest Yankee group report (Market Analysis Report 
on Data Communications Hardware) positions Nortel as the global market leader in 
ATM Wide Area Network equipment. 

Nortel's research capabilities around the world include a network of research and devel¬ 
opment facilities, affiliated joint ventures and other collaborations fostering innovative 
product development and advanced design research. With some 38 research and devel¬ 
opment sites in sixteen countries and territories, R&D spending in 1997 totalled 
approximately US$ 2.15 billion. Nortel reported 1997 revenues of US$ 15.45 billion. 
The company operates in more than 150 countries and territories and comprises 
approximately 73,000 employees world-wide. 

Power Networks 

A Power Network gives your business a competitive advantage; a business payback 
that can mean increased profitability. By transforming your disparate fragmented 
business networks into an integrated multimedia environment, a power network 
delivers increased performance to power your business goals. Power Networks are 
responsive, reliable, simple, secure and flexible - and deliver a lower cost of ownership 
than traditional networks. They can improve customer service, cut operating costs and 
give your people access to the information they need. 

Power Networks are based upon five cornerstone technologies: Wide area 
networking, Internet and intranet solutions, digital switching, multimedia appli¬ 
cations and mobility. 
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Wide Area Networking 

Nortel's wide area network solutions provide mission-critical, multimedia communica¬ 
tion support to businesses and service providers around the world. 

Nortel's future is based on technical excellence, forward-looking strategies, and strong 
partnerships with its customers. As users continue to demand higher bandwidth for 
their applications, and applications increasingly involve the integration of different 
traffic types, many organisations are being forced to re-examine their networking 
strategies. Nortel's goal is to help customers embrace this change rather than simply 
react to it. 

Nortel aims to: 

- Understand customer values and partner for success 

- Support new customer revenue and application opportunities 

- Provide fast delivery of leading-edge services 

- Maintain a vision for the future 

Passport 

Passport is an ATM-based network switch supporting multiple networkservices on a 
high-performance, high-capacity platform. In enterprise networks, Passport is a cost- 
effective network consolidation switch offering lower costs, greater functionality and 
readiness for multimedia applications. In service provider environments, it is used to 
build networks supporting frame relay, voice transport, ATM and SNA switching. 

Passport advantages: 

- Voice over any (ATM, Frame, IP) 

- Dynamic voice compression 

- Consolidation of data services 

- Dynamic bandwidth management 

- Diverse service offerings 

- Switched Virtual Circuits 

Passport Voice Networking 

This is a software package available for the Passport product which provides the ability 
for Passport to route individual voice calls based on the dialed digits.That is, the 
Passport network becomes, in effect, a distributed tandem voice switch, capable of 
understanding PBX signaling protocols. In effect, Passport delivers to the enterprise 
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network the ability to optimally route voice calls over an ATM enterprise network, 
delivering clear cost benefits to the corporation. Voice Networking can be summarized 
as, the Passport network nodes should act like a single tandem PBX offering virtual 
routing connectivity in a feature rich and manageable environment. 

Vector 

Nortel's standards-based 5 Gbit/s edge/backbone ATM switch which provides a powerful 
end-to-end networking solution, enables service providers to extend ATM networks and 
services to enterprise user locations. Vector was designed jointly with Fore Systems and 
delivers the most sought-after ATM features, including switched virtual connections for 
high-speed, on-demand connectivity, efficient routing and traffic management - to effec¬ 
tively support all types of traffic and various Quality of Service levels. 

Vector advantages: 

- Low cell transfer delays 

- Industry-leading traffic management and routing capabilities 

- Standards-based connection options 

- Market-leading connection resilience 

- Suite of interfaces 

- Data collection system 

Concorde 

Nortel's high-capacity ATM backbone switch which enables service providers to effi¬ 
ciently deploy and manage large ATM backbone networks. Its flexible and modular 
architecture supports online capacity increases, enabling service providers to leverage 
revenue opportunities from emerging high-bandwidth multimedia applications and 
services as and when they occur. 

Concorde advantages: 

- Industry-leading traffic management and standards-based connection options 

- Distributed architecture 

- Scaleable capacity 

- Fully redundant 

Management Systems 

Nortel's management systems provide a comprehensive set of solutions designed to 
address the operational needs of small enterprises and large service providers alike. 
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Management systems advantages: 

- Scaleable 

- An open solution 

- Comprehensive (applications for fault management requirements, configura¬ 
tion, performance, security and accounting) 

- Simple, easy-to-use 

- Extensive data collection 

Internet and Intranet 

Rapport and Entrust give you secure, reliable, high performance links to the Internet 
and corporate intranets. The Rapport dial-up switch portfolio is designed to provide 
remote access over a dial-up connection to LAN protocol based networks. A strategic 
entry point for New Licensed Operators and cable operators planning to enter dial-up 
markets, Rapport is targeted at residential users dialling into the Internet, or mobile and 
home workers dialling into corporate networks and intranets. Rapport offers service 
providers mass Internet access provision and the supply of Virtual Private Intranets to 
multiple enterprises. 

Rapport advantages: 

- Performance, reliability, security 

- Scaleable hardware configuration 

- Fully integrated solution 

The Entrust family of software products provide a server-based key management infra¬ 
structure. Unwanted visitors are locked out to ensure your site remains secure. 

Digital Switching 

Nortel is a digital switching leader, providing a full line of enterprise network 
switching systems, including the Meridian 1, Meridian SL-100, Multi-Media Carrier 
Switch (MMCS), Mercator and Norstar. 

Meridian 1 

Nortel's Meridian 1 is a digital Private Branch Exchange (PBX) designed to support 
between 30 and 10,000 lines. It evolved from the highly successful SL-1 system and 
was the first PBX designed for use in the global marketplace, offering customers a 
wide range of options to cope with different language needs as well as corporate 
networking requirements. 
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Meridian 1 is the best selling telephone system of its type in the world, with a global 
market of 14 per cent. Since its launch in 1990, over 120,000 systems have been sold, 
carrying more than 31 million lines in over 100 countries. In Europe alone, 7 million 
lines have been sold in over 24 countries, giving the Meridian 1 a 15 per cent share of 
the addressable market in this region. 

Flexibility and future-proofing - The Meridian 1 is an example of Nortel's 
"Evergreen" philosophy, which allows customers to upgrade systems as their 
organisations evolve and grow. This is achieved through the system's modular 
architecture which enables customers to add telephone sets, additional lines and 
extensions, as well as feature options. 

The system will also keep pace with new and emerging technologies, such as 
videoconferencing and broadband transmission, making these new applications 
available simply and without the need for total upgrade or change of equipment. 

The different telephone sets - Meridian M3110, M3310 M3820 and M2216 - 
offer the customer access to the range of features and facilities they have 
programmed into the system or purchased as optional extras. These range from 
simple autodial and call forwarding to more sophisticated ACD and conferenc¬ 
ing capabilities. 

Meridian SL-100 

Based on a carrier-grade platform, the Meridian SL-100 is Nortel’s largest PBX in the 
digital switching portfolio providing a solution to multimedia communications in large 
commercial enterprises and government environments. It has the flexibility to address 
current and future capacity and applications needs with its 60,000 digital voice or data 
line capacity. 

Multi-Media Carrier Switch (MMCS) 

MMCS is the leading entry-level carrier-grade switch providing the bridge between the 
carrier and enterprise network bringing advanced carrier functionality and intelligence 
to your business through such enhanced services as calling card and VPN. 

Mercator 

Mercator is a state-of-the-art, voice and data, multi-site communications system which 
provides sophisticated PBX features to smaller organisations or locations. The system 
supports applications and inter-working with Meridian 1. 
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Norstar 

Norstar is the best selling small business communications system around the world. 
Norstar systems are designed and built for integrated communications and are future- 
ready, adapting to changing business needs. 

Multi-media Communications 

Nortel's suite of Symposium applications will harness today's sophisticated media, 
creating an integrated portfolio of products and services to improve productivity and 
enhance customer relationships. Symposium is based on industry standards and 
commercially available hardware. This open platform flexibility means rapid applica¬ 
tion development for teleconferencing, electronic commerce, one-to-one marketing and 
other customised solutions. 

Mobility 

Companion provides an in-building wireless communication system to ensure that key 
individuals can be reached when they are away from their desks. The system consists 
of centralised controller units, radio base stations and portable telephones that provide 
facility-wide coverage. The system will integrate with the existing telephone exchange 
to allow you to make use of all the regular features whilst on the move about the 
building. Because there are no air-time charges. Companion substantially lowers the 
cost of mobile communication in the workplace. 


For any queries relating to this booklet or any of Nortel's products and services, please 
contact Nortel's Enterprise Networks team at the address below: 

Nortel (Northern Telecom) 

Enterprise Data Networks 
8200 Dixier Road 
Brampton, Ontario, M6T 5P6 
CANADA 

Tel: 1-800-4-N ORTEL 

(1-800-466-7835) 
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APPENDIX B - Introduction to Decibels 

Power levels used in telecommunication systems can vary significantly from one place 
to another, resulting in ratios that can involve very large numbers. Resultingly, Decibels 
are used instead of absolute powers because, by using the logarithm of the power ratio, 
more manageable numbers are obtained. 

Another factor leading to the use of logarithmic measures is that the ear is logarithmic 
in sensitivity. For example, a doubling in power delivered to the eardrum will be just 
enough for most people to notice. To double the perceived loudness requires the power 
to be increased by a factor of about ten. The ear also has a very large dynamic range 
i.e. the range of signal levels that can be perceived as sound and which extends from 
power levels at the eardrum of about 0.000000000000001 Watt up to about 0.001 Watt. 
This range can be more easily described as -120dBm up to OdBm (see below for a 
description of dBm). 

Because of these facts, telecommunication networks use logarithmic measures of 
power and ratios to describe signal levels as follows: 

The Decibel (dB) - The decibel is a logarithmic measure of the difference in power 
level between two points. For example it can be used to express the gain or loss 
between two ports of a telephone exchange or the gain or loss of a transmission line. If 
the powers to be related are PI and P2, then: 

Ratio in dB = 10 log 10 P2 

PI 

The sign of the dB value (+ or -) identifies which power is greater, i.e. if positive then 
P2 is greater than PI, if negative then P2 is less than PI. 

dBm - dBs refer to ratios of power, they do not refer to an absolute power level. To 
measure absolute level, the term dBm is used which is the absolute power expressed 
as the number of dB relative to 1 milliwatt (mW) e.g. -6dBm means a power level of- 
6dB (a ratio of a quarter) relative to lmW. OdBm means a power level of OdB (a ratio 
of 1) relative to lmW. 

dBr - dBr is a term used to express the difference in decibels between any point in a 
voice network and a reference point chosen as a zero relative level point. dBr is used 
to express relative transmission levels. 

It is normal in a digital network, to select the digital path as the OdBr point. 

dBmO - A value of power given in dBmO gives the actual power level of a signal with 
reference to a point of OdBr. It can be used to express the levels of signalling tones, 
noise, average speech levels etc.. 
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For example, with reference to Figure B.l, if we consider an analogue interface on a 
digital PBX that has a transmit relative level of +6dBr and a receive relative level of 
-8dBr, given an actual signal from the telephone of -9dBm, this is equivalent to a 
reference power of -15dBmO. This is because -9dBm into the interface will result in a 
power of -15dBm at the OdBr point. Similarly, in the opposite direction, an actual 
power of -8dBm measured at the telephone set, results from a power of OdBm at the 
OdBr point and is therefore equivalent to OdBmO. 



Figure B.l dBr reference levels 
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APPENDIX C - Glossary of Terms 


A-law 

AAL 

AC 

AC15 


ADPCM 

AIS 

AMI 

ATM 

B-ISDN 


B8ZS 

BNR 


CAS 

CBR 

CCITT 

CCS 


CDV 

CELP 

CHAS 

CO 

CPE 

CRC 


International version of 64kbit/s PCM digital speech. Defined in G.711. 

ATM Adaptation Layer. Used within an ATM network to convert the data 
from an end-user application into a form that fits into ATM cells. 

Alternating Current. 

Signalling system where signalling information is carried as in-band 
tones on a 4 wire circuit. Defined in BTNR (British Telecom Network 
Requirement) 181 but also adopted in some other European countries. 

Adaptive Differential Pulse Code Modulation. Speech compression 
technique offering speeds at 16, 24, 32 and 40kbit/s. Defined in G.726. 

Alarm Indication Signal. A sequence of all Is on a transmission system. 
Sometimes referred to as Blue Alarm. 

Alternate Mark Inversion. Physical level encoding technique. 

Asynchronous Transfer Mode. A communications technology that trans¬ 
ports all data types in fixed sized cells of 53 bytes. 

Broadband-Integrated Services Digital Network. A service or system 
requiring transmission channels capable of supporting rates greater than 
the primary rate (1.544Mbit/s or 2.048Mbit/s). 

Binary Eight Zeroes Substitution. Typically used on DS-1 digital PBX 
interfaces to overcome a low density of binary ‘Is’ in the digital stream. 

Bell Northern Research. Previous name for Nortel’s Research and 
Development organisation. The organisation now comes under the name 
Nortel Technology. 

Channel Associated Signalling. Used on digital interfaces for signalling. 

Constant Bit Rate. Refers to a bit stream that has a fixed bit rate. 

The International Telegraph and Telephone Consultative Committee. 
Now renamed the ITU-T. 

Common Channel Signalling. A data channel is used to carry signalling 
messages between telephone exchanges. Normally timeslot 16 on an El 
and timeslot 24 on a DS-1. 

Cell Delay Variation. In ATM, the variation in delay that the cells in a 
particular cell stream may experience across the network. 

Code Excited Linear Prediction. A form of speech compression with 
many implementations, some proprietary and some standard. 

Channel Associated Signalling. The same as CAS. 

Central Office. North American term for the PTO local exchange. 
Customer Premises Equipment. 

Cyclic Redundancy Check. 
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CS-ACELP 

CTS 

CVSD 

D4 

dB 

dBm 


dBmO 

dBr 

DC 

I)C ME 
DDI 


DL 

DPCM 

DPNSS 

DS-1 

DSI 

DSS1 

DTMF 

E&M 

El 

ECMA 

EDSS1 

EOC 

ER 

ERL 


Conjugate Structured-Algebraic Code Excited Linear Prediction. Version 
of CELP operating at 8kbit/s and defined in G.729. 

Clear To Send. 

Continuously Variable Slope Delta. Speech compression offering rates 
from 16kbit/s to 64kbit/s depending upon sampling rate. 

Framing type used on 1.544Mbit/s primary rate digital interfaces. 
Decibel. A logarithmic measure used to describe the power ratios. 

An absolute measure of power. Equal to the number of decibels relative 
to 1 milliwatt. OdBm = lmw. 

The absolute power at a point in a network relative to the OdBr point. 
Decibels relative. Used to express relative transmission levels. 

Direct Current. 

Digital Circuit Multiplication Equipment. 

Direct Dial In. A facility that allows users the ability to dial from a public 
network into a PBX and to a person’s extension without going via the 
operator. 

Data Link. Another name used for the FDL on ESF framed T1 links. 

Differential Pulse Code Modulation. A speech compression technique. 
The basis of ADPCM. 

Digital Private Network Signalling System. 

Digital interface speed of 1.544Mbit/s. 

Digital Speech Interpolation. A technique which makes use of the gaps in 
speech to reduce the amount of bandwidth required for transmission. 

Digital Signalling System 1. Generic term for the ITU-T defined ISDN 
signalling system. 

Dual Tone Multi Frequency. 

Ear & Mouth. The signalling leads used in E&M analogue trunk inter¬ 
faces. 

Refers to a transmission link that operates at a speed of 2.048Mbit/s. 
European Computer Manufacturers Association. 

European-DSSl. Another term used to describe Euro-ISDN. 

Embedded Operations Channel. Another name used for the FDL on ESF 
framed T1 links. 

Earth Recall. A facility on some telephone sets to provide a momentary 
grounding of one of the interface leads. 

Echo Return Loss. The amount of signal reflected back to the four wire 
path from a hybrid circuit. 


112 


Appendix C - Glossary of Terms 





Voice Fundamentals: From Analogue to ATM 


ESF 

Extended Superframe. Framing type used on 1.544Mbit/s primary rate 
digital interfaces. Offers enhanced capabilities over D4 framing. 

ETSI 

European Telecommunications Standard Institute. 

Euro-ISDN 

European wide implementation of ISDN. Based on ETSI specifications 
which are themselves based on ITU-T Recommendations. 

FDL 

Facility Data Link. A data channel carried within the ESF framing 
structure on a T1 link. 

FX 

Foreign Exchange. A term used in North America to describe a telephone 
service from a CO that is remote from (foreign to) the subscriber’s local 
exchange area. 

FXO 

Typically an interface on a multiplexer system that connects to a line card 
on an exchange to extend that interface out to a remote office. 

FXS 

Typically an interface on a multiplexer system that connects to a 
telephone set which is remote from the exchange that the telephone is 
connected to. 

HDB3 

High Density Bipolar 3. Used on El digital trunks. Defined in G.703. 

HDLC 

High Level Data Link Control. 

Hz 

Hertz. A measure of frequency in cycles per second. 

IP 

Internet Protocol. 

ISDN 

Integrated Services Digital Network. 

ISO 

International Standards Organisation. 

ITU-T 

Telecommunication Standardisation Sector of the International 
Telecommunication Union. Formerly the CCITT. 

kHz 

Thousands of Hertz. 

LAN 

Local Area Network. 

LAPD 

Link Access Procedures on the D channel. Layer 2 protocol used with 
various Common Channel Signalling protocols. 

LD-CELP 

Low Delay-Code Excited Linear Prediction. Low delay version of CELP 
operating at 16kbit/s and defined in G.728. 

Loop Disconnect 

A technique used for dialling digits with a basic 2-wire telephone set. 

p-law 

PCM type commonly used in North America and Japan. Defined in 
G.711. 

MCDN 

Meridian Customer Defined Networking. High functionality CCS 
protocol used between Meridian 1 PBXs. 

MFAS 

Multi-Frame Alignment Signal. 

MF 

Multi Frequency. 

MOS 

Mean Opinion Score. In our context it is a subjective measure of the 
quality of speech transmission systems such as with speech compression. 
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NLP 

Non Linear Processor. A function in an echo canceller used to remove 
residual echo. 

PABX 

Private Automated Branch Exchange. Usually shortened to PBX. 

PAM 

Pulse Amplitude Modulation. Used in the process of converting from an 
analogue signal to digital PCM. 

PBX 

Private Branch Exchange. 

PCM 

Pulse Code Modulation. Standardised method of producing digital 
speech. Defined in G.711. 

PM BX 

Private Manual Branch Exchange. 

POTS 

Plain Old Telephone Service. Basic telephone service on standard 2 wire 
telephone. No added features. 

PPS 

Pulses Per Second. 

PSS1 

Private Signalling System 1. Another term used to describe QSIG. 

PSTN 

Public Switched Telephone Network. 

Pulse Dial 

See Loop Disconnect. 

QD 

Quantisation Distortion. 

QDU 

Quantisation Distortion Unit. 

QSIG 

Internationally defined inter-PBX signalling standard. Defined in ETSI 
specifications. 

R&D 

Research & Development. 

RAI 

Remote Alarm Indication. Also referred to as Yellow Alarm. 

RPE-LTP 

Regular Pulse Excitation with Long Term Prediction. Speech compres¬ 
sion technique used on GSM mobile telephone system. 

RTS 

Ready To Send. Data interface signal. 

SAD 

Speech Activity Detection. Often called silence suppression. A technique 
used to stop the transmission of bits during periods of silence. See DSI 
and SAF. 

SAF 

Speech Activity Factor. The proportion of time that a person is actually 
making sound during a conversation. Typically 40% of the time. 

SEAL 

Simple Efficient Adaptation Layer. The same as AAL5 in ATM. 

SS7 

Signalling System number 7. Internationally defined inter-public 
telephone exchange signalling standard. Also known as CCS7. CCITT 
No. 7.” 

T1 

Refers to a transmission link that operates at a rate of 1.544Mbit/s. 

TBR 

Timed Break Recall. 

TDM 

Time Division Multiplex. 

Toll Quality 

The same quality speech as heard over the public telephone network. 
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Tie Trunk 

The name sometimes used to describe a trunk connecting (or tying) 
together PBXs in a private network. 

Tip/Ring 

The names sometimes used for the connections of a telephone circuit. 
The terms are derived from the plug used on manual exchanges. Tip was 
connected to the tip of the plug and Ring to the slip ring around the plug. 

VBR 

Variable Bit Rate. Refers to a bit stream that has a variable bit rate. e.g. 
speech with Speech Activity Detection operating. 

VoFR 

Voice over Frame Relay. 

VTOA 

Voice and Telephony Over ATM. 

WAN 

Wide Area Network. 

X.25 

Internationally accepted standard for packet switching networks. 
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Introduction to Quality of Service (QoS) 

Ralph Santitoro 


Introduction 

Quality of Service (QoS) is a broad term used to describe the 
overall experience a user or application will receive over a 
network. QoS involves a broad range of technologies, 
architecture and protocols. Network operators achieve end- 
to-end QoS by ensuring that network elements apply 
consistent treatment to traffic flows as they traverse the 
network. 

The goal of this paper is to put all of this into perspective 
and provide a holist view of the need for and the value of 
creating a QoS-enabled network. This paper will describe 
the relationship between the numerous technologies and 
acronyms used to describe QoS. 

This paper assumes that the reader is familiar with different 
networking technologies and architectures. This paper will 
provide answers to the following: 

• Why is a QoS-enabled network important? 

• What considerations should be made when deploying a 
QoS-enabled network? 

• Where should QoS be applied in the network? 

Why is QoS important? 

Today, network traffic is highly diverse and each traffic type 
has unique requirements in terms of bandwidth, delay, loss 
and availability. With the explosive growth of the Internet, 
most network traffic today is IP-based. Having a single end- 
to-end transport protocol is beneficial because networking 
equipment becomes less complex to maintain resulting in 
lower operational costs. This benefit, however, is countered 
by the fact that IP is a connectionless protocol, i.e., IP 
packets do not take a specific path as they traverse the 
network. This results in unpredictable QoS in a best-effort 
network. 

The IP protocol was originally designed to reliably get a 
packet to its destination with less consideration to the 
amount of time it takes to get there. IP networks must now 
support many different types of applications. Many of these 
applications require low latency. Otherwise, the end-user 
quality may be significantly affected or in some cases, the 
application simply does not function at all. 

Consider a voice application. Voice applications originated 
on public telephone networks using TDM (Time Division 
Multiplexing) technology which has a very deterministic 


behavior. On TDM networks, the voice traffic experienced a 
low and fixed amount of delay with essentially no loss. 

Voice applications require this type of behavior to function 
properly. Voice applications also require this same level of 
"TDM voice" quality to meet user expectations. 

Take this "TDM voice" application and now transport it over 
a best-effort IP network. The best-effort IP network 
introduces a variable and unpredictable amount of delay to 
the voice packets and also drops voice packets when the 
network is congested. As you can see, the best-effort IP 
network does not provide the behavior that the voice 
application requires. QoS techniques can be applied to the 
best-effort IP network to make it capable of supporting VoIP 
with acceptable, consistent and predictable voice quality. 

QoS and Network Convergence 

Since the early 1990s there has been a movement towards 
network convergence, i.e., transport all services over the 
same network infrastructure. Traditionally, there were 
separate, dedicated networks for different types of 
applications. However, many of these networks are being 
consolidated to reduce operational costs or improve profit 
margins. 

Not too long ago, an enterprise may have had a private 
TDM-based voice network, an IP network to the Internet, an 
ISDN video conferencing network, an SNA network and a 
multi-protocol (IPX, AppleTalk, etc.) LAN. Similarly, a 
service provider may have had a TDM-based voice network, 
an ATM or SONET backbone network and a Frame Relay or 
ISDN access network. 

Today, all data networks are converging on IP transport 
because the applications have migrated towards being IP- 
based. The TDM-based voice networks have also begun 
moving towards IP. Video conferencing is also moving 
towards IP albeit at a lesser pace. When the different 
applications had dedicated networks, QoS technologies 
played a smaller role because the traffic was similar in 
behavior and the dedicated networks were fine-tuned to meet 
the required behavior of the particular application. 

The converged network mixes different types of traffic, each 
with very different requirements. These different traffic 
types often react unfavorable together. For example, a voice 
application expects to experience essentially no packet loss 
and a minimal, constant amount of packet delay. The voice 
application operates in a steady-state fashion with voice 


Copyright 0 2001-2003 Nortel Networks. All Rights Reserved. 


Pane 1 




NS7RTEL 


NETWORKS' 


Introduction to Quality of Service (QoS) 


WPQOSGENOI vl.5 


channels (or packets) being transmitted in fixed time 
intervals. The voice application receives this performance 
level when it operates over a TDM network. Now take the 
voice application and run it over a best-effort IP network as 
VoIP (Voice over IP). The best-effort IP network has 
varying amounts of packet loss and potentially large 
amounts of variable delay (typically caused by network 
congestion points). The best-effort IP network provides 
almost exactly the opposite performance required by the 
voice application. Therefore, QoS technologies play a 
crucial role to ensure that diverse applications can be 
properly supported in a multiservice IP network. 


Bandwidth Owner versus Renter 

If the network operator owns the network connection's 
copper, fiber or frequencies (wireless), adding bandwidth to 
provide QoS may be an attractive choice in lieu of 
implementing more complicated QoS traffic management 
mechanisms. Some interconnect technologies, such as 
DWDM (Dense Wave Division Multiplexing) over fiber 
optic connections, allow bandwidth to be added simply and 
cost-effectively over the existing cable infrastructure. Other 
interconnect technologies, such as fixed or mobile wireless 
are much more constrained due to frequency spectrum 
limitations regulated by government agencies. 


"QoS technologies play a crucial role ... 
in a multiservice IP network." 


QoS versus Bandwidth 


Those who own their network 
connections have more choices than 
those who lease their bandwidth. 


Some believe that QoS is not needed and that increasing 
bandwidth will suffice and provide good QoS for all 
applications. They argue that implementing QoS is 
complicated and adding bandwidth is simple. While there is 
some truth to these statements, one first must look closer at 
the QoS problems to be solved and whether adding 
bandwidth will solve them. 

If all network connections had infinite bandwidth such that 
networks never became congested, then one would not need 


For example, a network operator has dark fiber in their 
backbone network and DWDM interfaces on their backbone 
switches. The operator has determined that sufficient 
bandwidth is no longer available to provide the network 
users with the required performance objectives. In this 
scenario, it is simpler and more cost effective to add 
additional wavelengths to provide QoS by increasing 
bandwidth than add complicated QoS traffic management 
mechanisms. 


to apply QoS technologies. Indeed, there are parts of some 
Carrier networks that have tremendous amounts of 
bandwidth and have been carefully engineered to minimize 
congestion. However, high-bandwidth connections are not 
available throughout the network, from the traffic's source to 
the traffic's destination. This is especially true for access 


Those who lease their network 
connections are more constrained 
with their bandwidth choices. 


networks where the most commonly available bandwidth is 
typically only hundreds of kbps. Furthermore, bandwidth 
discontinuities in the network are potential congestion points 
resulting in variable and unpredictable QoS that a user or 
application experiences. 

Carriers have been aggressively adding bandwidth to their IP 
networks to meet the exploding demand of the Internet. 

Some carriers can offer low latency connections across their 
metropolitan area networks (MANs) or cross-country or 
continental long haul networks. Traffic must be treated 
consistently to achieve a subscribed QoS level. If the access 
network aggregation point is a congestion point in the 
network, the resulting end-to-end QoS can be poor even 
though the long-haul network may offer excellent QoS 
performance. 


For example, a network operator provides best-effort 
services and rents (leases) bandwidth from another service 
provider. This network operator wants to offer a premium 
data services with performance guarantees. Through the 
application of QoS mechanisms, this network operator can 
offer service differentiation between the premium data 
service and best-effort subscribers. For a lightly to 
moderately loaded network, this may be accomplished 
without increasing bandwidth. Hence, for the same fixed 
recurring cost of this leased bandwidth, the network operator 
can offer additional, higher-priced services and increase 
profit margins. 

QoS Performance Dimensions 

A number of QoS parameters can be measured and 
monitored to determine whether a service level offered or 
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received is being achieved. These parameters consist of the 
following: 

• Network Availability 

• Bandwidth 

• Delay 

• Jitter 

• Loss 

There are also QoS performance-affecting parameters that 
cannot be measured but provide the traffic management 
mechanisms for the network routers and switches. These 
consist of: 

• Emission priority 

• Discard priority 

Each of these QoS parameters affects the application’s 
performance or end-user's experience. 

Network Availability 

Network availability can have a significant affect on QoS. 
Simply put, if the network is unavailable, even during brief 
periods of time, the user or application may achieve 
unpredictable or undesirable performance (QoS). 

Network availability is the summation of the availability of 
many items that are used to create a network. These include 
networking device redundancy, e.g., redundant interfaces, 
processor cards or power supplies in routers and switches, 
resilient networking protocols, multiple physical 
connections, e.g., fiber or copper, backup power sources, etc. 
Network operators can increase their network's availability 
by implementing varying degrees of each of these items. 

The greatest challenge for network 
operators today is to provide highly 
available IP networks. 


Bandwidth 

Bandwidth is probably the second most significant 
parameter that affects QoS. Bandwidth allocation can be 
subdivided into two types: 

• Available Bandwidth 

• Guaranteed Bandwidth 

Available Bandwidth 

Many network operators oversubscribe the bandwidth on 
their network to maximize the return on investment of their 
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network infrastructure or leased bandwidth. 

Oversubscribing bandwidth means the bandwidth a user 
subscribed to is not always available to them. This allows 
all users to compete for available bandwidth. They get more 
or less bandwidth depending upon the amount of traffic from 
other users on the network at any given time. 

Available bandwidth is a technique commonly used over 
consumer ADSL networks, e.g., a customer signs up for a 
384kbps service that provides no QoS (bandwidth) guarantee 
in the SLA. The SLA points out that the 384kbps is 
"typical" but does not make any guarantees. Under lightly 
loaded conditions, the user may achieve 384kbps but upon 
network loading, this bandwidth will not be achieved 
consistently. This is most noticeable during certain times of 
the day when more users access the network. 

Guaranteed Bandwidth 

Network operators offer a service that provides a guaranteed 
minimum bandwidth and burst bandwidth in the SLA. 
Because the bandwidth is guaranteed, the service is priced 
higher than the Available Bandwidth service. The network 
operator must ensure that those who subscribe to this 
Guaranteed Bandwidth service get preferential treatment 
(QoS bandwidth guarantee) over the Available Bandwidth 
subscribers. 

In some cases, the network operator separates the 
subscribers by different physical or logical networks, e.g., 
VLANs, Virtual Circuits, etc. In some cases, the 
Guaranteed Bandwidth service traffic may share the same 
network infrastructure with the Available Bandwidth service 
traffic. This is often the case at locations where network 
connections are expensive or the bandwidth is leased from 
another service provider. When subscribers share the same 
network infrastructure, the network operator must prioritize 
the Guaranteed Bandwidth subscribers' traffic over the 
Available Bandwidth subscribers' traffic so that in times of 
network congestion, the Guaranteed Bandwidth subscribers' 
SLAs are met. 

Burst bandwidth can be specified in terms of amount and 
duration of excess bandwidth (burst) above the guaranteed 
minimum. QoS mechanisms may be activated to discard 
traffic that is consistently above the guaranteed minimum 
bandwidth that t he subscriber agreed to in the SLA 

Delay 

Network delay is the transit tune an application experiences 
from the ingress point to the egress point of the network. 
Delay can cause significant QoS issues with applications 
such as voice and video, and applications such as SNA and 
Fax transmission that simply time-out and fail under 
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excessive delay conditions. Some applications can 
compensate for a small amount of delay but once a certain 
amount is exceeded, the QoS becomes compromised. 

For example, some networking equipment can "spoof 1 an 
SNA session on a host by providing local 
acknowledgements when the network delay would cause the 
SNA session to time-out. Similarly, VoIP gateways and 
phones provide some local buffering to compensate for 
network delay. 

Finally, delay can be both fixed and variable. Examples of 
fixed delay are: 

• Application-based delay, e.g., voice codec processing 
time and IP packet creation time by the TCP/IP software 
stack 

• Data transmission (queuing delay) over the physical 
network media at each network hop 

• Propagation delay across the network based on 
transmission distance 

Examples of variable delays are: 

• Ingress queuing delay for traffic entering a network 
node 

• Contention with other traffic at each network node 

• Egress queuing delay for traffic exiting a network node 

"Some applications can compensate for finite 
amounts of delay but once a certain amount is 
exceeded, the QoS becomes compromised." 


Jitter 

Jitter is the measure of delay variation between consecutive 
packets for a given traffic flow. Jitter has a pronounced 
effect on real-time, delay-sensitive applications such as 
voice and video. These real-time applications expect to 
receive packets at a fairly constant rate with fixed delay 
between consecutive packets. As the arrival rate varies, the 
jitter impacts the application's performance. A minimal 
amount of jitter may be acceptable but as jitter increases, the 
application may become unusable. 

Some applications, such as voice gateways and IP phones 
can compensate for a small amount of jitter. Since a voice 
application requires the audio to play out at a constant rate, 
if the next packet does not arrive within the playback time, 
the application will replay the previous voice packet until the 
next voice packet arrives. However, if the next packet is 


delayed too long, it is simply discarded when it arrives 
resulting in a small amount of distorted audio. 

All networks introduce some jitter because of variability in 
delay introduced by each network node as packets are 
queued. However, as long as the jitter is bounded, QoS can 
be maintained. 


"... as long as the jitter is bounded, 
QoS can be maintained." 


Loss 

Loss can occur due to errors introduced by the physical 
transmission medium. For example, most landline 
connections have very low loss as measured in the Bit Error 
Rate (BER). However, wireless connections such as 
satellite, mobile or fixed wireless networks, have a high 
BER that varies due to environment or geographical 
conditions such as fog, rain, RF interference, cell handoff 
during roaming and physical obstacles such as trees, 
buildings and mountains. Wireless technologies often 
transmit redundant information since packets will inherently 
get dropped some of the time due to the nature of the 
transmission medium. 

Loss can also occur when congested network nodes drop 
packets. Some networking protocols such as TCP 
(Transmission Control Protocol) offer packet loss protection 
by retransmitting packets that may have been dropped or 
corrupted by the network. When a network becomes 
increasingly congested, more packets are dropped and hence 
more TCP retransmissions. If congestion continues, the 
network performance will significantly decrease because 
much of the bandwidth is being used to retransmit dropped 
packets. TCP will eventually reduce its transmission 
window size resulting in smaller and smaller packets being 
transmitted. This eventually will reduce congestion 
resulting in fewer packets being dropped. 

Because congestion has a direct impact on packet loss, 
congestion avoidance mechanisms are often deployed. One 
such mechanism is called Random Early Discard (RED). 
RED algorithms randomly and intentionally drop packets 
once the traffic reaches one or more configured thresholds. 
RED takes advantage of the TCP protocol's window size 
throttling feature and provides more efficient congestion 
management for TCP-based flows. Note that RED only 
provides effective congestion control for applications or 
protocols with "TCP-like" throttling mechanisms. 
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Emission Priorities 

Emission priorities determine the order in which traffic is 
forwarded as it exits a network node. Traffic with a higher 
emission priority is forwarded ahead of traffic with a lower 
emission priority. Emission priorities also determine the 
amount of latency introduced to the traffic by the network 
node's queuing mechanism. 

For example, delay-tolerant applications such as email 
would be configured to have a lower emission priority than 
delay-sensitive real-time application such as voice or video. 
These delay-tolerant applications may be buffered while the 
delay-sensitive applications are being transmitted. 

In its simplest of forms, emission priorities use a simple 
transmit priority scheme whereby higher emission priority 
traffic is always forwarded ahead of lower emission priority 
traffic. This is typically accomplished using strict priority 
scheduling (queuing). The downside of this approach is that 
low emission priority queues may never get serviced 
(starved) if there is always higher emission priority traffic 
with no bandwidth rate limiting. 

A more elaborate scheme provides a weighted scheduling 
approach to the transmission of traffic to improve fairness, 
i.e., the lower emission priority traffic doesn't always have to 
wait until the higher emission priority traffic is transmitted. 
Finally, some emission priority schemes provide a mixture 
of both priority and weighted schedulers 

Discard Priorities 

Discard priorities are used to determine the order in which 
traffic gets discarded. The traffic may get dropped due to 
network node congestion or when the traffic is out-of- 
profile, i.e., the traffic exceeds its prescribed amount of 
bandwidth for some period of time. 

Under congestion, traffic with a higher discard priority gets 
dropped before traffic with a lower discard priority. Traffic 
with similar QoS performance requirements can be 
subdivided using discard priorities. This allows the traffic to 
receive the same performance when the network node is not 
congested. However, when the network node is congested, 
the discard priority is used to drop the "more eligible" traffic 
first. 

Discard priorities also allow traffic with the same emission 
priority to be discarded when the traffic is out-of-profile. 
Without discard priorities, traffic would need to be separated 
into different queues in a network node to provide service 
differentiation. This can be expensive since only a limited 
number of hardware queues ( typically eight or less) are 
available on networking devices. Some devices may have 


software-based queues but as these are increasingly used, 
network node performance is typically reduced. 

With discard priorities, traffic can be placed in the same 
queue but in effect, the queue is subdivided into virtual 
queues, each with a different discard priority. For example, 
if a product supports three discard priorities, then one 
hardware queue in effect provides three QoS levels. 

Application Requirements 

Table 1 illustrates the QoS performance dimensions required 
by some common applications. As you can see from this 
table, applications can have very different QoS 
requirements. As these are mixed over a common IP 
transport network, without applying QoS technologies, the 
traffic will experience unpredictable behavior. 

"... without applying QoS technologies, the 
traffic will experience unpredictable behavior." 



Performance Dimensions 

Application 

Bandwidth 

Sen 

Delay 

sitivity 

Jitter 

to 

Loss 

VoIP 

Low 

High 

High 

Med 

Video 

Conferencing 

High 

High 

High 

Med 

Streaming Video 
on Demand 

High 

Med 

Med 

Med 

Streaming Audio 

Low 

Med 

Med 

Med 

Client / Server 
Transactions 

Med 

Med 

Low 

High 

Email 

Low 

Low 

Low 

High 

File transfer 

Med 

Low 

Low 

High 


Table 1: Application Performance Dimensions 


Categorizing Applications 

Networked applications can be categorized based on end- 
user expectations or application requirements. Some 
applications are between people while other applications are 
between a person and a networked device's application, e.g., 
and PC and a web server. Finally, some applications are 
between networking devices, e.g., router-to-router. 

Table 2 categorizes applications into four different traffic 
categories, namely. Interactive, Responsive. Timely and 
Network Control. The table also includes example 
applications that fall into the different categories. 
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Network 

Control 

Critical Alarms, Routing, 
Billing, Critical OAM 

Interactive 

VoIP, Interactive Gaming, 
Video Conferencing 

Responsive 

Streaming audio/video, 
Client/Server Transactions 

Timely 

Email, Non-critical OAM 


Table 2: Application Traffic Categories 


Interactive Applications 

Some applications are "interactive" whereby two or more 
people actively participate. The participants expect the 
networked application to respond in "real-time". In this 
context, "real-time" means that there is minimal delay 
(latency) and delay variation (jitter) between the sender and 
receiver. Some interactive applications, such as a telephone 
call, have operated in real-time over the telephone 
companies' circuit switched networks for over 100 years. 
The QoS expectations for voice applications have been set 
and therefore must also be achieved for packetized voice 
such as VoIP. 


Responsive Applications 

Some applications are between a person and a networked 
device's application. End users require these applications to 
be "responsive" so a request sent to the networking device 
requires a relatively quick response back to the sender. 

These applications are sometimes referred to as being "near 
real-time". These applications require relatively low packet 
delay, jitter and loss. However, QoS requirements for 
responsive applications are not as stringent as real-time, 
interactive application requirements. This category includes 
streaming media and client/server transaction-based 
applications. 

Steaming media applications include Internet radio (talk 
radio and music) and audio/video broadcasts (news, training, 
education and motion pictures). Streaming applications 
require the network to be responsive when they are initiated 
so the user doesn't wait too long before the media begins 
playing. These applications also require the network to be 
responsive for certain types of signaling. For example, with 
movies on demand, when one changes channels or 
"forwards", "rewinds" or "pauses" the media, one expects 
the application to react similarly to the response time of their 
VCR controls. 


Other interactive applications include video conferencing 
and interactive gaming. Since the interactive applications 
operate in real-time, packet loss must be minimized. 

Imagine if you were speaking over the telephone and lost 
parts of a word every so often during the conversation. This 
QoS level would be unsatisfactory. 

Interactive applications typically are UDP-based (Universal 
Datagram Protocol) and hence cannot retransmit lost or 
dropped packets as with TCP-based (Transport Control 
Protocol) applications. However, packet retransmission 
would not be beneficial because interactive applications are 
time-based. For example, if a voice packet was lost, it 
doesn't make sense for the sender to retransmit it because the 
conversation has already progressed and the lost packet 
might be from part of the conversation that has already 
passed in time. 


Interactive applications expect 
the network QoS to provide 
packets with the lowest possible 
delay, jitter and loss. 


Web-based applications typically involve the user selecting a 
hyperlink to jump to a new page or submit information 
(place an order, submit a request, etc.) These applications 
also require the network to be responsive such that once the 
hyperlink is selected, a response, e.g., a new page begins 
loading, occurs typically within 1-2 seconds. With 
broadband Internet connections, this is often achieved over a 
best-effort network, albeit inconsistently. These types of 
applications may include a financial transaction, e.g., place 
credit card order and quickly provide feedback to the user 
indicating the transaction has completed. Otherwise, the 
user may be unsure the transaction completed and attempt to 
initiate a duplicate order (unknowingly). Alternatively, the 
user may assume that the order was placed correctly but it 
may not have. In either case, the user will be dissatisfied 
with network or application's performance. 

Responsive applications can use either UDP or TCP-based 
transport. Streaming media applications typically use UDP 
(but can also use TCP). Web-based applications are based 
on the HyperText Transport Protocol (HTTP) and always 
use TCP. For Web-based applications, packet loss is 
managed by TCP which retransmits lost packets. 
Retransmission of lost streaming media packets is typically 
handled by application-level protocols as long as the media 
is sufficiently buffered. If not, then the lost packets are 
discarded resulting in some distortions in the media (audio 
or video). 
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Responsive applications expect the 
network QoS to provide packets 
with a relatively low amount of 
delay, jitter and loss. 


Timely Applications 

Some applications between a person and networked device's 
application do not require "near real-time" performance but 
do require the information to be delivered in a timely 
manner. Such examples include store and forward email 
applications and file transfers. The relative importance of 
these applications is based on their business priorities. 

These applications require that the packets arrive with a 
bounded amount of delay. For example, if an email takes a 
few minutes to arrive at its destination, this is acceptable. 
However, in a business environment, if an email took 10 
minutes to arrive at its destination, this is often unacceptable. 
The same bounded delay applies to file transfers. Once a 
file transfer is initiated, delay and jitter are inconsequential 
because file transfers often take minutes to complete. Note 
that timely applications use TCP-based transport and 
therefore, packet loss is managed by TCP which retransmits 
any lost packets resulting in no packet loss. 

In summary, timely applications expect the network QoS to 
provide packets with a bounded amount of delay. Jitter has 
a negligible effect on these types of applications. Loss is 
reduced to zero due to TCP’s loss recovery mechanisms. 

"Timely applications expect the 
network QoS to provide packets 
with a bounded amount of delay." 


Network Control Applications 

Some applications are used to control the operation and 
administration of the network. Such applications include 
network routing protocols, billing applications and QoS 
monitoring and measuring for SLAs. These applications can 
be subdivided into those required for critical and standard 
network operating conditions. To create high-availability 
networks, network control applications require "priority" 
over end-user applications because if the network is not 
operating properly, end-user application performance will 
suffer. 


In summary, network control applications require a 
relatively low amount of delay. Jitter has a negligible effect 
on these types of applications. Loss needs to be minimized 
because some of the applications are not transported via TCP 
and hence do not have lost packet recovery mechanisms. 


"Network control applications require 
a relatively low amount of delay. 

Loss needs to be minimized" 

QoS Technologies - A Layered 
Approach 

Building a QoS-enabled network requires a number of 
different QoS technologies. Figure 1 provides a quasi-OSI 
model of the different QoS technology layers. Some QoS 
technologies used to measure and monitor QoS services span 
all layers. The intent here is not to delve into each of the 
technologies. The intent is to provide an understanding of 
where each of these QoS technologies can be used and the 
benefit they provide. 

"Building a QoS-enabled 
network requires a number of 
different QoS technologies." 
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Figure 1: QoS Technologies 


Physical Layer QoS 

These technologies allow for the separation ot traffic. The 
separation and prioritization may take the form of 
wavelengths (lambdas). Virtual Circuits (VCs). ports on a 
device or frequencies over the air. This is the simplest form 
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of QoS whereby different levels of QoS are provided 
through traffic separation at the physical layer. For example, 
the blue wavelength may provide a priority service and the 
red wavelength may provide a best-effort service. In some 
cases, this type of QoS can be inexpensive, e.g., adding 
additional wavelengths over an existing fiber optic cable. 
However, this approach can also be very expensive if the 
resources are leased or limited, e.g., frequency spectrum. 

Link Layer QoS 

Each link layer has a different type of QoS technology that 
can be applied. The most common link layers are Ethernet, 
ATM, PPP, MPLS, DOCSIS (HFC cable). Frame Relay and 
Mobile wireless technologies (only UMTS / 3GPP will be 
discussed here). The following sections will provide a brief 
overview of the different link layer QoS technologies. For 
additional details, references are provided at the end of this 
document. 

Ethernet 

Ethernet (IEEE 802.3) provides 2 different QoS 
mechanisms. One mechanism is via 802.Ip which provides 
8 classes of service. The other mechanism is via VLANs 
whereby traffic can be separated, isolated and prioritized by 
the VLAN ID. VLANs allow for the logical grouping of 
users or devices with similar QoS or security requirements. 
Although VLANs are layer 2-based, users belonging to the 
same VLAN do not need to be physically connected to the 
same Ethernet subnet. VLANs most commonly allow for 
traffic separation and prioritization based on the particular 
Ethernet switch port to which a user is connected (called 
port-based VLANs). VLANs can also be created based on 
Ethernet MAC addresses, protocol types or other user- 
defined information for the Ethernet switches to classify. 

ATM 

The ATM Forum created ATM service categories, each with 
different QoS traffic management parameters and 
performance levels. The most widely available ATM 
service categories are CBR (Constant Bit Rate), rt-VBR 
(real-time Variable Bit Rate), nrt-VBR (non real-time VBR) 
and UBR (Unspecified Bit Rate). In general, CBR is used 
for circuit emulation services (including circuit-based voice 
or video transport), rt-VBR is used for real-time packet- 
based voice or video services, nrt-VBR is used for priority 
data services and UBR is used for best-effort data services. 

Other ATM service categories defined that are less widely 
available are ABR (Available Bit Rate) and GFR 
(Guaranteed Frame Rate) both of which are enhancements 
over the UBR service and provide additional service 
guarantees that are not provided by UBR. 


ATM also provides a number of traffic management 
parameters for each of the ATM service categories such as 
Peak Cell Rate (PCR), Sustained Cell Rate (SCR) and Cell 
Loss Priority (CLP). These parameters define the traffic's 
performance level in the particular ATM service category. 

PPP 

When using PPP over a low-bandwidth connection, the IP 
packets are typically fragmented to reduce queuing delay. 
Each packet fragment can be assigned a PPP Class Number 
to use for service differentiation. When the packets arrive at 
a PPP session termination point for reassembly, the Class 
Numbers are used to determine the service class to which the 
particular packet fragments belong. 

Two PPP multi-class formats are supported. The short 
sequence number format provides 4 classes of service and 
the long sequence number format provides 16 classes of 
service. 

MPLS 

MPLS provides for 2 different forms of QoS determined by 
the EXP (Experimental) bits in the MPLS shim header. 

When using E-LSPs (EXP-inferred Label Switched Paths), 
the EXP bits provide 8 service classes that support both 
emission and discard priorities and Differentiated Services 
(DiffServ) traffic class behaviors. When using L-LSPs 
(Label-inferred LSPs), the EXP bits provide 8 discard 
priorities. 

MPLS also supports a number of traffic management 
parameters to define the behavior the traffic will receive as it 
traverses a particular LSP. 

DOCSIS 

The DOCSIS protocol is used over HFC cable networks and 
has been proposed for use over fixed wireless networks. The 
DOCSIS protocol supports QoS via traffic separation 
through the use of Service IDs (SIDs). There are four SIDs. 
They are rtPS (real-time Polling Service), nrtPS (non real¬ 
time Polling Service), UGS (Unsolicited Grant Service), 
UGS-AD (Unsolicited Grant with Activity Detection) and 
BE (Best Effort Services). rtPS is used for bursty real-time 
services such as video and VoIP with silence suppression. 
nrtPS is used for bursty, non real-time flows such as web 
browsing. UGS is used for periodic real-time flows such as 
VoIP. UGS-AD is used for intermittent yet periodic real¬ 
time flows such as VoIP with Voice Activity Detection 
(VAD). 

Frame Relay 

Frame Relay has a QoS mechanism called Discard 
Eligibility (DE) that can be set by the networking device for 
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traffic that can be discarded under network congestion. 

Frame relay also provides a Committed Information Rate 
(CIR) and Excess Information Rate (EIR) that define the 
minimum and burst bandwidth guarantees, respectively. 

UMTS Wireless Networks 

The 3rd-Generation Partnership Project (3GPP) has defined 
wireless networks that are the first to offer QoS through 
service differentiation. UMTS (Universal Mobile 
Telecommunications System) standards have defined 4 
wireless traffic classes used for traffic separation. The four 
classes are Conversational, Streaming, Interactive and 
Background. UMTS networks provide traffic management 
parameters such as Allocation/Retention priorities used to 
determine the forwarding behavior of the traffic. 

Traffic-Engineered Paths 

As traffic traverses a network, it can often take different 
paths depending upon the networking technology. For 
example, routed IP networks are connectionless, i.e., a 
packet can take different paths. Because there is not a 
dedicated path for the traffic to traverse, QoS can become 
less predictable under network congestion. Because network 
operators want to offer service level guarantees, network 
paths can be engineered to provide guaranteed QoS 
performance. Traffic that is within the service level criteria 
can be steered to these traffic engineered paths and obtain a 
predictable QoS level. 

Network-Signaled QoS 

MPLS and ATM use signaling protocols to request a desired 
QoS level from other network nodes prior to connection 
establishment (known as connection admission control or 
CAC). ATM uses a protocol called PNNI (Private Network- 
Network Interface) to accomplish this. MPLS uses a 
protocol called LDP (Label Distribution Protocol) to set up 
the Label-Switched Paths (LSPs). To signal QoS for these 
traffic-engineered paths, MPLS uses RSVP-TE (RSVP for 
Traffic Engineered paths) or CR-LDP (Constraint-based 
Routed LDP). RSVP-TE provides extensions to and uses 
the basic RSVP protocol to setup stateful connections 
between MPLS Label Edge Routers (LER) and Label Switch 
Routers (LSR). CR-LDP uses the TCP protocol to setup 
connections between the LERs and LSRs. Both protocols 
achieve similar goals through different approaches. 

IP QoS via DiffServ 

DiffServ (Differentiated Services) defines a number of 
services classes and QoS mechanisms that are applied to 
packets in those service classes (called Per-Hop Behaviors 
or PHBs). The DiffServ Code Point (DSCP) located in the 
IP packet header and is used to determine the PHB. Note 
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that the DSCP occupies the TOS (Type of Service) field yet 
is not compatible with it. (DiffServ has replaced the TOS 
field definition). The standard PHBs each have a unique 
DSCP associated with them. The DSCP is used to determine 
the respective DiffServ behavior the packet is to receive. 
Different types of applications have different traffic 
characteristics and require different types of QoS behaviors 
to be applied to them. Note that custom PHBs can also be 
created using a unique DSCP to identify them. 

Expedited Forwarding DiffServ Class 

The Expedited Forwarding (EF) D.iffServ behavior provides 
a low-latency, high-priority service that is ideally suited for 
VoIP. The EF behavior is implemented with a high (or 
highest) emission priority and lowest discard priority. 
Basically, in order to achieve the required behavior, each 
network node must ensure that the EF traffic has the lowest 
possible delay, jitter and loss since the service is attempting 
to emulate a leased line over an IP network. 

Assured Forwarding DiffServ Class 

The Assured Forwarding (AF) DiffServ behavior consists of 
four different service classes, each with 3 different discard- 
priority levels. 

Each AF class also has three different discard priorities 
(drop precedence levels) resulting in twelve different DSCP 
values. Routers use these drop precedence values to 
determine the discard priority of packets under network 
congestion. Table 3 lists the different AF classes by discard 
priorities. 


Discard 

Priority 

Class 1 

AF C 

Class 2 

lass 

Class 3 

Class 4 

Low 

API 1 

AF21 

AF31 

AF41 

Medium 

AF12 

AF22 

AF32 

AF42 

High 

AF13 

AF23 

AF33 

AF43 


Table 3: Assured Forwarding DiffServ Classes 


Class Selector DiffServ class 

The Class Selector (CS) DiffServ behavior may be 
represented by eight priority classes and uses the same bit 
positions as the IP Precedence field in the TOS definition. 

In this usage, the CS7 DSCP has the highest emission 
(forwarding) priority and the CSO DSCP has the lowest 
forwarding priority. CSO is equivalent to a "best effort” 
service. Note that the CS behavior does not support discard 
priorities. 

Class Selector DSCPs may also be used to indicate other 
standardized DiffServ behaviors. For example, a router may 
be configured such that packets marked with the CSS DSCP 
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receive Expedited Forwarding (EF) behavior. In this 
example, packets marked with either CS5 and EF will 
receive Expedited Forwarding behavior by the router. This 
is useful where different applications require the same 
DiffServ behavior but their bandwidth is managed separately 
using the different DSCP value. 

Default DiffServ class 

The DEfault (DE) DiffServ behavior is used to transport 
best-effort traffic. Any traffic that is not classified into 
another standard or custom DiffServ PHB must be 
transported using the DE PHB. The DE DSCP value is 0 
and typically has the highest discard priority and lowest 
emission priority. 

QoS Measurement and Monitoring 

Service providers need to ensure that their networks are 
properly engineered to support new services such as IP 
telephony, video on demand (movies), interactive learning 
and video conferencing services. These services cannot be 
offered without certain QoS-related network capabilities. 

In order to offer such services to subscribers, the network 
QoS must be measured and monitored to ensure that the 
service is being adequately supported. Furthermore, since 
the QoS performance may be specified in a Service Level 
Agreement (SLA) the service provider needs to ensure that 
the network is providing the performance as specified. The 
SLA may consist of parameters such as maximum packet 
loss (over some time interval) and maximum packet delay. 

The SLA specifies the terms and conditions of the service 
being offered. Once a service provider can accurately 
measure the network capabilities and provide a guaranteed 
performance level, he can confidently offer a billable service 
to his subscribers. 

Subscribers also want to monitor network performance to 
ensure that they receive the services to which they subscribe. 
Therefore, the service provider should also provide the 
subscriber with tools to monitor network QoS statistics that 
are relevant for the particular SLA. 

Making QoS Simple 

After reading through this document, you will quickly 
conclude that QoS can be quite a complicated topic and 
there are many different technologies, standards and network 
architectures to consider. Furthermore, there is no single 
QoS technology or standard that can be used across your 
network. How can QoS be simplified? 


In 1999, Nortel Networks started simplifying QoS by 
creating standardized, default QoS configurations and 
behaviors for its products in the form of end-to-end network 
service classes. These are called Nortel Networks Service 
Classes (NNSC) and the NNSCs are a superset of the QoS 
Classes defined in the ITU-T Y.1541 standard. The NNSCs 
have been defined based upon the most common types of 
applications as illustrated in Table 5. The NNSCs provide 
default settings and behaviors for the different QoS 
technologies. 




HH 

Network 

Control 

Critical Alarms 

Critical 

Routing, Billing, 
Critical OAM 

Network 

Interactive 

IP Telephony 

Premium 

Video Conferencing, 
Interactive Gaming 

Platinum 

Responsive 

Streaming audio/video 

Sold 

Client/Server Transactions 

Silver 

Timely 

Email, non-critical OAM 

Bronze 

Best Effort 

Standard 


Table 5: Nortel Networks Service Classes (NNSC) 


The NNSCs have been designed to provide the appropriate 
behavior required for different types of applications. A 
service provider or Enterprise network manager determines 
the services to be offered and the application to be 
supported. Based on this information, the network elements 
are configured to place the traffic into the NNSC that 
provides the closest performance behavior required by the 
application or service offering. Services can now be quickly 
added using the NNSCs’ default QoS behaviors while not 
having to deal with the underlying QoS technologies 
required to create the service behaviors. 

NNSCs are being built into Nortel Networks product but can 
also be created in other vendors' products through QoS 
policy management systems. The default behaviors would 
be created in the policy management systems and the device- 
specific configuration rules (commands) would then be 
transmitted to the device. 

QoS Performance Consistency 

In order to maintain QoS performance for a given service 
offering. QoS technologies must be implemented 
consistently across the network. Since IP is the predominant 
networking protocol, IP QoS is offered across the network 
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using DiffServ. However, implementing DiffServ to provide 
end-to-end QoS is not sufficient because packets traverse 
different link layers, each with their unique QoS 
technologies. Therefore, in order to achieve consistent end- 
to-end QoS performance, DiffServ must be mapped to the 
different link layer QoS technologies. 

Mapping DiffServ to Link Layer QoS 

DiffServ provides a standard set of service classes known as 
per hop behaviors (PHBs). These PHBs also provide a 
standardized DiffServ Code Point (DSCP) value associated 
with the PHB. Therefore, the DSCP must be mapped to the 
different link layer QoS to provide the closest behavior 
possible to create an end-to-end service. 

There are many possible approaches to mapping IP QoS to 
link layer QoS. The following sections will provide sample 
default link layer mapping that can be used to provide 
consistent behavior between the IP and link layer QoS 
technologies. 

Mapping DiffServ over Ethernet 

Ethernet provides 8 classes of service via the three 802. Ip 
bits. These 8 classes traditionally have been used to provide 
8 priority levels. DiffServ can be mapped to the Ethernet 
802. Ip user priorities as illustrated in Table 6. 


DiffServ Code 

Ethernet 802.1 p 

Point (DSCP) 

User Priority 

CS7.CS6 

7 

EF, CS5 

6 

AF4x',CS4 

5 

AF3x'. CS3 

4 

AF2x',CS2 

3 

AFlx'.CSl 

2 

DE, CS0 

0 


x=l, 2 or 3 

Table 6: Mapping DiffServ' to Ethernet 802.Ip 


Note that in this example, 802. Ip user priority 1 is not used. 
802.Ip user priority 0 must be the default for best-effort 
traffic which is why it is mapped to the DE (Default) 
DiffServ PHB. 

Mapping DiffServ over ATM 

The most popular ATM service categories are CBR, rt-VBR, 
nrt-VBR and UBR. DiffServ can be mapped to these as 
illustrated in Table 7. By mapping DiffServ to the ATM 
service categories, IP QoS behavior is preserved over the 
ATM link layer. 
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DiffServ Code 
Point (DSCP) 

ATM Service 
Category 

CS7, CS6, CS5, EF 

CBR or rt-VBR 

AF4x‘,CS4 

rt-VBR 

AF3x'. CS3 

AF2x',CS2 

nrt-VBR 

AFlx', CS1 

DE, CS0 

UBR 


x=l, 2 or 3 

Table 7: Mapping DiffServ to ATM Service Categories 

Mapping DiffServ over PPP 

When using PPP over a low-bandwidth connection, the 
fragmented IP packets are assigned a PPP Class Number. 

By mapping DifTServ-marked packets to the PPP Class 
Numbers as illustrated in Table 8, IP QoS is preserved 
across the PPP connection. 

Note that EF-marked traffic is marked with the highest PPP 
Class Number. This is done because the queuing delay over 
a low-bandwidth connection is high and therefore the EF- 
marked traffic must be transmitted ahead of all other traffic 
to meet its strict QoS delay requirements. 


DiffServ 
Code Point 
(DSCP) 

PPP Class Number 
(long sequence number format) 

EF 

7 

CS7.CS6.CS5 

6 

AF4x'.CS4 

5 

AF3x'. CS3 

4 

AF2x',CS2 

3 

.AFlx 1 , CS1 

2 

DE, CS0 

1 


1 x=l, 2 or 3 

Table 8: Mapping DiffServ to PPP Class Numbers 


Nortel Networks Service Class 
Mapping 

Nortel Networks Service Classes (NNSCs) allow network 
operators to construct end-to-end services. The NNSCs 
provide the default mapping and QoS behaviors as 
illustrated in Table 9. Traffic is classified and placed into a 
NNSC which provides the default QoS behaviors in each 
network router and switch. Products that do not natively 
support NNSCs can have the NNSC behavior constructed 
using a QoS policy management system such as Nortel's 
Optivity Policy Services. 


Introduction to Quality of Service (QoS) 
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NNSC 

DiffServ 
Code Point 
(DSCP) 

ATM 

Service 

Category 

PPP 

Class 

Numbers 

802.1 p 
User 
Priority 

Critical 

CS7 

rt-VBR 

6 

7 

Network 

CS6 

Premium 

EF, CS5 

CBR or 
rt-VBR 

7 

6 

Platinum 

AF4x',CS4 

rt-VBR 

5 

5 

Gold 

AF3x',CS3 

4 

4 

Silver 

AF2x',CS2 

nrt-VBR 

3 

3 

Bronze 

AFlx 1 , CS1 

2 

2 

Standard 

DE, CSO 

UBR 

1 

0 


1 x=l, 2 or 3 

Table 9: NNSC QoS technology mapping 


Summary 

QoS technologies are required for every type of network. 
Low-bandwidth and leased bandwidth connections often 
require more complex QoS technologies to be implemented 
to provide adequate performance levels while maximizing 
bandwidth efficiency. The degree to which these are 
applied depends upon the services being offered to the 
subscriber. Finally, end-to-end services require QoS 
technologies to be implemented consistently across the 
network in order to achieve the performance required by 
certain applications or specified in an SLA to a subscriber. 
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QoS Recommendations for VoIP 

Ralph San+itoro and John Hagerty 


Introduction 

Many considerations need to be made before installing a 
VoIP system on an existing, best-effort IP network 
infrastructure. This document provides an overview of the 
different QoS systems and makes recommendations on how 
they should be used. 

Quality of Service Systems 

Why do you need QoS Systems? 

Most IP networks treat all traffic the same and are referred to 
as "best-effort" networks. Because of this, the traffic may 
experience different amounts of packet delay, loss or jitter at 
any given time. These types of traffic "impairments" result 
in the quality of the voice signal that the user will hear such 
as: 

• Sneech Break-up . This causes the speech to sound 
distorted like the speech experienced on a digital cell 
phone when the signal is getting out of range. 

• Sneech Clipping . This causes parts of words to get 
cutoff. 

• Pons and clicks . This is caused when voice packets are 
dropped. 

• Echo . This is caused by the your voice getting reflected 
back to you from the remote end. 

In today's TDM-based voice systems, the voice traffic 
experiences a fixed amount of delay and essentially no 
packet loss due to the structure of the circuit-switched 
telephone network resulting in very high quality voice. For 
VoIP systems, a QoS system is needed because voice over 
IP networks do not traverse along fixed, dedicated circuits 
with a small, constant amount of delay and no packet loss as 
in circuit-switched telephone networks. 

IP networks are "connectionless", i.e., the voice traffic can 
take different paths from source (caller) to destination 
(called party) and the voice traffic also shares those paths 
with other types of traffic. QoS systems are required to 
ensure that voice traffic also experiences the high quality 
transmission needed to meet current user expectations. 

Some data networks may be over-provisioned such that there 
is plenty of unused bandwidth available. While this may 
provide sufficient QoS for VoIP some of the time, it cannot 
provide QoS consistently during times of congestion or 
during transmission peaks of bursty data traffic. A QoS 
system eliminates these events that can impair the voice 
quality. 


TOS and DiffServ - What's the 
Difference? 

The 2nd-byte of the IP packet header contains an 8-bit field 
used for IP QoS. The original definition of that field was 
referred to as the TOS (Type Of Service). In 1999, the 
IETF (Internet Engineering Task Force) that is responsible 
for IP standards created a new QoS system and has redefined 
this byte to now be called the DiffServ (Differentiated) 
Service Field. 

TOS 

The TOS byte is broken down into 2 sub-fields, namely, the 
3-bit IP Precedence field and the 3-bit TOS (D/T/R) field. 
The two, least significant bits of the field are always set to 
zero. Figure 1 illustrates the different sub-fields. 

MSB LSB 

+-+-+-+--I-H-+-+-+ 

|PRECEDENCE | D | T | R | 0 | 0 | 

+ -+-+-+-+-+-+-+-+ 

Figure 1: TOS Field 

Of these 2 sub-fields, the D/T/R bits 
(Delay/Throughput/Reliability) were rarely used and only 
the IP Precedence field was used. Legacy routers that do 
support IP QoS typically support only the IP Precedence 
field. These 3 bits result in 8 classes of service. 
Unfortunately, many people refer to a router supporting TOS 
when they really mean IP Precedence. 

MSB LSB 

H-1-1-H-H-H-H-1-+ 

|PRECEDENCE | 0 | 0 | 0 | 0 | 0 | 

+ -+-+-+- 1 --+-+-+-+ 

Figure 2: IP Precedence Field in TOS Field 

DiffServ 

In 1999, the IETF created IP Differentiated Services 
(DiffServ) to replace the older IP QoS definitions of the 
TOS field. The DiffServ field uses the same TOS field but 
the definition of the bits and purpose of them is now quite 
different. Like TOS, not all 8 bits are used and only the 
most-significant 6 bits are used while the last 2 bits are 
always set to zero. This 6-bit value is referred to as the 
DiffServ Code Point (DSCP). 

The value of the DSCP is used to define the DiffServ class 
to which the traffic belongs and the type of treatment the 
traffic will receive. Out of the 64 possible values for the 
DSCP, only 32 are available for public use while the other 
32 are defined for experimental use. 
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MSB LSB 

+-+-+-+-+-+-+-+-+ 

| DSCP | 0 | 0 | 

+-+-+-+-+-H-+-+-+ 

Figure 2: DiffServ use of the TOS field 

Twenty-one of the 32 DSCPs have been standardized by the 
IETF leaving 11 DSCPs that can be used for user-defined 
purposes. 

IP QoS through DiffServ 

DiffServ defines a number of different 'services classes’ and 
QoS mechanisms that are applied (called Per-Hop Behaviors 
or PHBs) to packets in those service classes. These PHBs 
each have an IETF-standardized DSCP associated with them 
so that packets marked with these DSCPs can be determined 
to be in the respective DiffServ class. Different types of 
applications have different traffic characteristics and require 
different types of QoS behaviors to be applied to them. 

Class Selector DiffServ class 

The Class Selector (CS) DiffServ behavior is represented by 
eight priority classes and uses the same bit positions as the 
IP Precedence field in TOS. The CS7 (‘111000’) DSCP has 
the highest forwarding (emission) priority and the CSO 
(‘000000’) DSCP has the lowest forwarding priority. CSO is 
equivalent to a “best effort” service. 


Forwarding 

Priority 

CS Code 
Point Name 

CS Code 
Point Value 

Highest 

. 

CS7 

'll 1000' 

CS6 

'll 0000' 

_ 

CS5 

'101000' 


CS4 

T 00000' 


CS3 

'011000' 


CS2 

'010000' 


CS1 

'001000' 

Lowest 

CSO 

'000000' 


Table 1: Class Selector Code Points 


Expedited Forwarding DiffServ class 

The Expedited Forwarding (EF) DiffServ behavior provides 
a low-latency, high-priority service that is ideally suited for 
VoIP. The EF DSCP is represented by the binary value 
‘101110’. Note that the term 'EF' is not a hexadecimal value 
but an abbreviation of Expedited Forwarding. 

Assured Forwarding DiffServ Class 

The Assured Forwarding (AF) DiffServ behavior consists of 
four different service classes, each with 3 different discard- 
priority levels. 


Each AF class has three different discard priority (drop 
precedence) levels resulting in twelve different DSCP 
values. Routers use these drop precedence values to 
determine the discard priority of packets under network 
congestion. Note that the term 'AF' is not a hexadecimal 
value but an abbreviation of Assured Forwarding. 


Discard 

Priority 

AF Class 

Class 1 

Class 2 

Class 3 

Class 4 

Low 

'001010' 
(AF11) 

'010010' 

(AF21) 

'011010' 

(AF31) 

T 00010' 
(AF41) 

Medium 

'001100' 

(AF12) 

'010100' 

(AF22) 

'011100' 

(AF32) 

T00100' 
(AF42) 

High 

'001110' 

(AF13) 

'010110' 

(AF23) 

'011110' 

(AF33) 

'100110' 
(AF43) 


Table 2: Assured Forwarding DiffServ Classes 


Configuring DiffServ 

When configuring DiffServ values (DSCP) with which to 
mark packets, be careful about how the device implements 
the DSCP. While the DiffServ field is an 8-bit value, the 
DSCP is only a 6-bit value. Some devices require you to 
configure an 8-bit value (DSCP + 00). Some devices require 
you to configure only the actual 6-bit DSCP value. In this 
case, the devices would pad this 6-bit value with 2 zeros to 
offer 64 contiguous values. For example, the 6-bit DSCP 
value for Expedited Forwarding (EF) is '101110' (binary), 

2E (hexadecimal) or 46 (decimal). The 8-bit DiffServ field 
value for Expedited Forwarding (DSCP+00) is '10111000' 
(binary), B8 (hexadecimal) and 184 (decimal). Note that 
you would see this 8-bit value instead of the 6-bit DSCP if 
you used a network analyzer to look at the DiffServ byte. 

DiffServ for VoIP 

If you currently have a best-effort IP data network and are 
just adding VoIP, the simplest approach is to construct your 
network QoS such that there are only 3 levels of traffic 
priorities. One priority is for VoIP media (bearer) traffic. 
The second priority is for VoIP signaling traffic. The third 
priority is for you best-effort IP data traffic. Routers 
connected to low-bandwidth interfaces must separate voice 
media and voice signaling packets to minimize voice jitter 
that would be introduced by the signaling packets to the 
voice media packets. This jitter would occur if the packets 
were not separated and placed in the same queue. This will 
be discussed in more detail in the section entitled "VoIP over 
Low-Bandwidth Connections". 


RECOMMENDATION: Use DiffServ traffic classes as 
indicated in the following table:_ 



a 

a 

S A 
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DiffServ 

Class 

IHINtM 

DSCP 

(decimal) 

Voice media 

Expedited 

Forwarding 

T01110' 

46 

Voice 

signaling 

Class 
Selector 5 

T01000’ 

40 

Data traffic 

Default 

’000000’ 

0 


Ethernet 802.1 Q 

This is an IEEE Ethernet standard that adds 4 additional 
bytes to the standard 802.3 Ethernet frame for Ethernet QoS 
and Virtual LAN (VLAN) support. Most Ethernet switches 
support the 802. IQ standard with the exception of perhaps 
the least expensive ones. 


RECOMMENDATION: Use 802.1p user priorities 
indicated in the following table: 




Voice media and signaling 

T10' 

6 

Data traffic 

'000' 

0 


Making QoS Simple 

After reading through this document, you will quickly 
conclude that QoS is quite a complicated topic and there are 
many different technologies, standards and implementations 
to consider. Furthermore, there is no single QoS technology 
or standard that can be used across your network. How can 
QoS be simplified? 


Ethernet 802. Ip 

The Ethernet QoS is accomplished via the three 802.Ip User 
Priority bits. 



Figure 3: 802.1p Priority bits in the 802.1Q Tag 

The 802.Ip User Priority bits are used to create 8 classes of 
service for packets traversing Ethernet networks. Table 3 
includes the definitions for each of the 802. IQ fields. 


802.1 Q Field 

Description 

Protocol Identifier 

Always set to 8100h for Ethernet 
frames (802.3 tag format) 

3-bit priority field 
(802.Ip) 

Value from 0-7 representing user 
priority levels (7 is the highest) 

Canonical Field 
Identifier 

Always set to 0 

12-bit 802.IQ 

VLAN ID 

VLAN identification number 


Table 3: 802.1Q Field Definitions 


Nortel Networks has embarked upon simplifying QoS by 
creating standardized, default QoS configurations and 
behaviors for its product in the form of end-to-end network 
service classes. These are called Nortel Networks Service 
Classes (NNSC). The NNSCs have been defined based 
upon the most common types of applications. The NNSCs 
provide default mapping between DiffServ and different link 
layer QoS technologies that a particular interface uses, e.g., 
802.Ip for an Ethernet interface. The NNSCs also provide 
default mapping of these QoS technologies to a specific 
queue on an interface. 


Traffic 

Category 

V-, ' f-4- . . •: S ' '"'t - . 

Example Application 

Nortel 

Networks 

Service 


Class 

Network 

Control 

Critical Alarms 

Critical 

Routing, Billing, 
Critical OAM 

Network 


IP Telephony 

Premium 

Interactive 

Video Conferencing, 
Interactive Gaming 

Platinum 

Responsive 

Streaming audio/video 

Gold 

Client/Server Transactions 

Silver 

Timely 

Email, non-critical OAM 

Bronze 

Best Effort 

Standard 


Table 4: Nortel Networks Service Classes (NNSC) 


NNSCs provide the following default QoS settings for the 
following: 

• DiffServ Code Point 

• Link layer QoS, e.g., Ethernet 802.1 p User Priority 

• Queue in which traffic is placed 

• Traffic Management Parameters 

• Traffic Schedulers 
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NNSCs can also be created in other non-Nortel products 
through device configuration or QoS policy management 
systems. 

Nortel Networks has defined the Premium NNSC to be used 
for IP Telephony applications such as VoIP. Table 5 
outlines some of the default attributes of the Premium 
NNSC. Note that the link layer QoS attributes will be 
specific for a given interface type. For example, an Ethernet 
interface will use 802.1 p while an ATM interface will not. 


Other methods to achieve QoS 

Depending upon the application, different and often simpler, 
QoS mechanisms can be applied. DiffServ is used to 
provide IP QoS services across the network. However, 

802.Ip may not be necessary to provide QoS for your VoIP 
traffic for your layer 2 Ethernet switches. QoS could be 
achieved by methods described below. 

Port Prioritization 


QoS 

Attribute 

Premium NNSC default setting 

(4 queue system example) 

DSCP 

Voice Media - Expedited Forwarding 

Voice Signaling Class Selector 5 

Link Layer 
QoS 

802.Ip User Priority 6 

ATM CoS = CBR or rt-VBR 

PPP Class Number 3 

Scheduler 

Priority 

Policer 

Drop packets exceeding configured rate 


Table 5: Default Premium NNSC settings-4 queue system 


How do NNSCs simplify QoS? 

The best way to illustrate this is by an example. Suppose 
you are deploying VoIP services over an existing best-effort 
IP data network in your facility. Before you introduce the 
VoIP service, you need to QoS-enable your network. 

VoIP Gateways and IP Phone Configuration 

Your VoIP gateways and IP phones would be configured to 
pre-mark the VoIP packets for the Premium NNSC, i.e., 
voice media packets marked with the 'EF' DSCP and voice 
signaling packets marked with the 'CS5' DSCP. Note that 
you could bypass this step with some Nortel Networks 
products that already provide you with these default settings. 


If you are adding a VoIP gateway, it will connect to a 
specific port on your Ethernet L2 switch so you would 
configure the L2 switch to prioritize all traffic coming from 
the port. In this case 802.Ip is not required because you are 
prioritizing all traffic coming in on this port. 


If the device attached to the L2 switch port is an IP phone, 
then port prioritization is not recommended since IP phones 
may be unplugged and moved. If a PC were connected to a 
port configured to use port prioritization, then all of the PC's 
traffic would be given high priority treatment. 



Figure 4: Port-based prioritization example 


IP Routers and L2/L3 switches Configuration 

You need to QoS-enable your networking devices and 
configure them to place the VoIP traffic into the Premium 
NNSC. This is accomplished by configuring your data 
networking equipment to provide Premium NNSC treatment 
to all 'Premium-marked' packets. Some Nortel Networks 
products already perform this by default when QoS is 
enabled on a particular interface. Otherwise, you will have 
to configure all of the many configuration settings (e.g., 
priority scheduler, tail drop policer, link layer QoS setting, 
etc.) that the Premium NNSC would automatically provide 
for you by default. 


Traffic Separation using VLANs 

All voice traffic can be placed into one VLAN and all other 
data traffic into another VLAN. The "Voice" VLAN traffic 
can be prioritized over the "Data" VLAN traffic. In some 
cases, this may be the easiest method if all Ethernet switches 
supports the 802.1Q standard for VLANs. VLANs can also 
be used to separate traffic for security purposes. 
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Figure 5: VLAN example 


IP Address Prioritization 

VoIP traffic can also be prioritized by its IP address. This 
approach is ideal for devices with statically assigned IP 
addresses that rarely, if ever, change. IP PBXs, VoIP 
gateways and call servers are VoIP devices that would have 
their IP addresses statically assigned. A network 
administrator can configure the routers to filter (classify) and 
prioritize all packets originating from these IP addresses and 
know they are from VoIP devices. 



Figure 6: IP address-based prioritization example 

In this example any traffic entering the router from IP 
address 10.10.10.1 will get priority over any other traffic. 


RECOMMENDATION. For stationary IP telephony 
devices such as VoIP gateways, use port prioritization on the 
Ethernet switch port that connects to the device. 


Other Considerations 

There may be other items to consider when setting up your 
QoS enabled network. For example, do you "trust" your 
network connections or VoIP devices connected to your 
network? If the network is under your complete 
administrative control, e.g., private IP network, then you 
may have control over and hence trust the VoIP devices 
attached to your network. It is possible for VoIP devices, 
e.g., IP phones and gateways, to generate packets that are 
pre-marked with QoS settings (DiffServ DSCP or Ethernet 
802. Ip) that you have provisioned. Can you trust those 
devices to mark their VoIP packets with the appropriate QoS 
markings? 

Packet Marking for QoS 

Some VoIP devices such as IP phones and gateways can pre- 
mark packets with QoS settings prior to transmitting them to 
the network. These devices could mark the DiffServ Code 
Point (DSCP) and perhaps also the Ethernet 802.Ip user 
priority. If the VoIP devices cannot provide pre-mark 
packets, then you have to rely on the routers or policy 
switches to perform this marking. Some products such as 
the Nortel Networks Business Policy Switch and Passport 
8600 can classify, mark and prioritize based on both DSCP 
and Ethernet 802.Ip. 

RECOMMENDATION: Use DiffServ packet marking 
unless other routers or L3 switches in your network only 
support IP Precedence. Also use Ethernet 802.Ip user 
priorities to tag your VoIP packets if your voice devices 
support this capability^ 


VoIP Packet Scheduling 

It is important that all VoIP packets be queued in a router or 
switch using a strict priority scheduler whereby VoIP 
packets will receive priority treatment over all other packets. 
This is required to minimize voice traffic delay but more 
importantly, minimize the delay variation 0> Rer ) introduced 
to the voice traffic. Because a strict priority scheduler can 
"starve" the servicing of all other traffic queues, you need to 
set a threshold to limit the maximum amount of bandwidth 
that the VoIP traffic can consume. Most products allow you 
to set this and it is often called "rate limiting". 

Other "weighted" schedulers such as Weighted Round Robin 
(WRR) or Weighted Fair Queuing (WFQ) are NOT 
RECOMMENDED. If your router or switch does not 
support a priority scheduler and only supports a weighted 
scheduler, then the queue weight for VoIP traffic should be 
configured to 100%. If you cannot configure a 100% weight 
due to some product limitation, then you should consider 
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replacing the product because it will cause unpredictable 
voice quality. 

RECOMMENDATION: Use a strict priority scheduler for 
VoIP _ 

VoIP over Low-Bandwidth 
Connections 

There are a number of items to consider when using routers 
with low-bandwidth WAN and access network connections 
such as xDSL and Packet Cable. This section will 
specifically discuss WAN connections but the techniques 
and recommendations described also apply to other low- 
bandwidth access network connections such as xDSL and 
Packet Cable. 


throughput to perhaps an unacceptable level. Adding VoIP 
to the existing WAN data network may require the WAN 
bandwidth to be increased. 

Example: A company has 2 sites that are connected via a 
leased line WAN connection operating at 128kbps. This 
bandwidth is sufficient for the current data requirements. 

The company believes that it only needs 70-80kbps most of 
the time with occasional traffic peaks up to the full 128kbps. 
The company wants to support up to 4 simultaneous voice 
calls over the IP WAN network between the sites. If all 4 
calls were simultaneously active, this would require 96kbps 
(using a G.729 codec) of the available 128kbps of the 
connection leaving only 32kbps remaining for the data 
traffic. This is not sufficient based on the company's 
business needs. 


Per call bandwidth 

The amount of bandwidth a VoIP call uses depends on 
whether the voice signal is compressed and what link layer 
protocol the VoIP packet uses for transport. It is desirable 
to compress your voice signals when using VoIP over a low- 
bandwidth connection. There are several possible choices 
for voice compression. The ITU G.729 codec provides the 
lowest bandwidth yet highest voice quality. G.729 
compresses the voice call from 64kbps down to 8kbps. This 
8kbps is the "raw voice” bandwidth and needs to be 
encapsulated into other protocols before it becomes VoIP 
and can be transported over an IP network. The link layer 
protocol to transport the IP packet could be PPP, Frame 
Relay or ATM. The additional overhead added by these 
protocols increases bandwidth required for VoIP packets to 
24kbps. (Note that the 24kbps is based on 20ms voice 
samples.) 

Voice compression is not required over high bandwidth, 
Ethernet connections. This uncompressed voice is encoded 
using the ITU G.711 codec resulting in 64kbps of "raw 
voice" bandwidth. The voice gets encapsulated into IP and 
Ethernet to create a VoIP packet which requires 80kbps of 
total bandwidth. (Note that the 80kbps is based on 20ms 
voice samples.) 

Bandwidth Example 

One of the main attractions of VoIP is the ability to use an 
existing WAN data network infrastructure to save on inter¬ 
office toll calls. However, offices often connect over low- 
bandwidth WAN connections so special considerations must 
be made when adding VoIP over a bandwidth-limited 
connection. When VoIP calls are active, the routers are 
typically configured to reduce the data traffic throughput by 
the amount of bandwidth for the VoIP call, e.g., 24kbps per 
call over a PPP connection. This will reduce the data traffic 


Solution: Upgrade the WAN connection bandwidth. 


RECOMMENDATION: Use G.729 codec to compress 
voice traffic over low-bandwidth connections. Budget 
24kbps of bandwidth for each simultaneous G.729 call. 

Do not use any voice compression over high bandwidth 
connections. Budget 80kbps of bandwidth for each 
simultaneous G.711 (uncompressed) call._ 


DelaylLatency 

The overall "delay budget" for a voice call from the time you 
speak to the time the receiver hears your voice should 
typically be no longer than 200ms for good quality voice 
over landline connections. (The amount of delay is often 
longer but unavoidable for satellite and other types of 
wireless connections). Studies have shown that as the 200 
ms delay budget is exceeded, most users tend to perceive the 
delay resulting in more dissatisfaction in voice quality. 

Every time a VoIP packet passes through a device or 
network connection, delay is introduced. A significant 
amount of delay can be introduced over low-bandwidth 
connections. 

Reducing Delay Through Packet 
Fragmentation 

In mixed voice/data IP networks, packets must be 
fragmented prior to traversing bandwidth-limited (<lMbps) 
connections to minimize voice delay and jitter. There are 
several different protocols that can be used to fragment 
packets. For Frame Relay connections, you can use the 
FRF. 12 standard for fragmenting packets. ATM natively 
provides fragmentation since all packets are fragmented into 
53-byte ATM cells. Both of these fragmentation techniques 
are acceptable. However, there are two types of 
fragmentation that are more universal and not limited to a 
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specific link layer technology such as ATM or Frame Relay. 
These methods are via the PPP protocol and via IP 
fragmentation. 

PPP Fragmentation and Interleaving 

Many routers support PPP Fragmentation. PPP 
fragmentation splits large packets into multiple smaller 
packets and encapsulates them into PPP frames before 
queuing and transmission. PPP fragmentation allows 
higher-priority VoIP packets to interrupt and transmit ahead 
of the remainder of larger, lower-priority packets that have 
already been queued. The packets may be interleaved so the 
maximum delay a voice packet will experience is one packet 
time. 

For example, a voice (small) packet enters a router followed 
by a large data packet which is followed by a second voice 
packet. The first voice packet begins to get transmitted as 
the first fragment. Next, the first fragment of the data packet 
is transmitted. Next, the second voice packet is transmitted. 
Finally, the second fragment of the data packet is 
transmitted. If no more packets enter the router, then the 
data packet fragments will continue to be transmitted until 
the entire data packet is transmitted. 


RECOMMENDATION: PPP is the preferred method for 
packet fragmentation. IP fragmentation can also be used if 
your router does not support PPP fragmentation. 


The following table provides the recommended maximum 
MTU sizes for different connection speeds when using IP 
fragmentation: 



Connection Rate (kbps) 


56 

64 

128 

256 

512 

Maximum MTU (bytes) 

128 

128 

256 

512 

1024 


Link Utilization for VoIP Traffic 

Over low-bandwidth connections, the amount of VoIP traffic 
should be limited to a percentage of the bandwidth of the 
connection. This is done to minimize the maximum queuing 
delay that the VoIP traffic experiences over low-bandwidth 
connections. 


RECOMMENDATION: For low-bandwidth (<lMbps) 
connections, you can use up to 50% of the available 
bandwidth for voice traffic. For connections > 1Mbps, you 
can use up to 85% of the available bandwidth for voice 
traffic. _ 


IP Fragmentation 

All routers support IP fragmentation whereby all IP packets 
are configured to a size determined by the MTU (Maximum 
Transmission Unit). Most routers use a default maximum 
packet size of 1500 bytes which can take a considerable 
amount of time to transmit over a low-bandwidth 
connection. Consider a 1500-byte data packet being 
transmitted over a 64kbps connection. It would take 188ms 
to transmit this data packet out of the router onto the 64kbps 
connection. This same queuing delay is added again as the 
packet is queued in at the far-end router on the other side of 
the connection. In general, a desirable end-to-end delay for 
a voice packet to achieve high quality is less than 200ms. So 
you can see that this data packet uses up almost the entire 
delay budget for the voice traffic before the first voice 
packet is ever transmitted ! 

Over bandwidth-limited connections (<lMbps), if PPP 
fragmentation is not used, the router must be configured to 
transmit smaller packets by adjusting the MTU size for the 
IP packets. The MTU size is adjusted to achieve a 
maximum delay of 20ms over the different connection 
speeds. Therefore, a higher bandwidth connection will have 
a larger MTU size than a lower bandwidth connection. 


Packet Reordering 

In some cases there may be multiple paths for a VoIP packet 
to take when traveling from its source to its destination. If all 
VoIP packets do not take the same path then packets could 
arrive out of order. This can cause voice quality issues even 
though packet reordering often has little or no adverse affect 
on data traffic quality. 

Example: If two locations are connected using two Frame 
Relay PVCs, you must ensure that all voice traffic for a 
specific call traverses the same PVC. The routers can be 
configured to direct voice packets from the same 
source/destination IP address to traverse the same VC. 
Another approach is to configure the router to send all voice 
traffic over only one of the PVCs. 

VoIP over Ethernet Networks 

Ethernet networks require less sophisticated QoS 
mechanisms than low-bandwidth WAN connections because 
the bandwidth is much higher resulting in significantly lower 
queuing and network delay. However, network congestion, 
even for short periods of time and bursty, TCP-based 
Internet traffic can cause significant voice quality problems 
if QoS were not applied. 

Only switched-media Ethernet networks should be used with 
VoIP. Shared-media Ethernet hubs must never be used. 
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QoS mechanisms described earlier, such as 802.Ip, VLANs 
and Port prioritization can be used for VoIP traffic over 
Ethernet networks. If the Ethernet switches support layer 3 
capabilities, then QoS mechanisms such as DiffServ, IP 
Address prioritization can also be used. 

Summary 

VoIP requires QoS systems to be implemented in your IP 
network to ensure predictable and acceptable performance. 

You now are armed with a basic understanding of the 
different QoS technologies to consider when deploying 
VoIP. 
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VoIP Network Assessment Guidelines 

Mark D. Lewis 


Introduction 

This document will help the reader to better understand the 
challenges faced when deploying VoIP and help the network 
designer obtain a better knowledge of the network to ensure 
a successful VoIP deployment. Each question is described in 
detail in this document with specific recommendations for 
each relevant section. 

Three phases of assessment 

There are three phases of assessment that can determine 
what needs to be done to further answer the questions below. 
The goal of the assessment is to determine if the network can 
support VoIP with a consistent level of quality based on the 
expectations of the customer. 

1. Customer states that the network is VoIP ready. 

2. Pre-Sales Engineer performs a readiness audit. 

a. Begin with questions below 

b. Utilize customers existing NMS to collect SNMP 
and RMON statistics. 

c. Use simple auditing tools available. NetlQ Qcheck, 
VoIP Bandwidth Calculator and the Multi-Router 
Traffic Grapher tool. 

d. Utilize passive monitoring tools such as Network 
Associates Sniffer Pro or active tools such as NetlQ 
Chariot. 

3. Network Designer engages Nortel Networks 
Professional Services to perform a true audit of the 
customers network. 

Network Assessment Questions 

Successful deployment begins with a network assessment 
and begins with several important questions that need to be 
answered in order to begin the process. These questions are 
not a replacement for a comprehensive network audit; an 
overview of some basic tools to evaluate an IP network is 
included in this document. 

1. Is a physical network diagram available for the data and 
voice network? 

a. Is a logical diagram for both networks available? 

2. What types of links are in use? PPP, FR. ATM? 

a. What link speeds are in use on the LAN/WAN? 

3. What is the current utilization of those links? 

a. What are the peak delays on the WAN links? 

4. What LAN/WAN platforms are currently installed? 

a. Do the currently installed platforms support some 
form of QoS? 

5. What protocols are in use? 

a. What routing protocols are in use? . 

6. What is the current flow of data and voice traffic? ' 


a. Is a Call Detail Record available? 

7. What is the expected voice quality? 

a. What MOS score and (or) R Value is expected? 

Logical assessment flow 

The following chart is a logical view of what steps are 
necessary to assess a network to ascertain readiness for 
VoIP. This document will outline the steps to successfully 
deploy VoIP. 
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Physical and Logical Network Diagrams (1/1 a) 

In order to ascertain VoIP readiness, a diagram of both the 
data and voice infrastructure physical and logical are 
required. These diagrams are invaluable when determining 
the platforms deployed in the network as well as the logical 
design such as the IP addressing architecture, link speeds 
and connectivity. From a voice perspective, the numbering 
plan and call detail record will help determine calling 
patterns in a multi-site environment. 

The routing of TDM trunking facilities should help when 
determining utilization and bandwidth requirements for a 
VoIP deployment. For example when deploying in a point to 
point environment, overhead for the proposed VoIP traffic is 
at a minimum however, when deploying VoIP in an ATM 
environment the overhead associated with transporting 
relatively small (200 bytes) data packets into smaller cells 
this can become a burdensome challenge. See Table 1 for 
figures that show bandwidth usage for given CODEC types 
and packet sample times. 

Link Types and Speeds (2/2a) 

When considering VoIP in a WAN environment where link 
speeds are typically low compared to the LAN, the speeds of 
the links are an important consideration as speeds under 
1 Mbps subject VoIP to serialization delay that can impair 
deployment. When transporting smaller VoIP packets over 
an infrastructure that typically has packet sizes up to 1500 
bytes, these larger packets can introduce variable delay 
(jitter) in the network and in turn impact the quality of voice. 


Figure 1: Network Diagram 


Codec Type 

Payload Size 

IP 

Packet 

Ethernet 

Bandwidth 2 

PPP 

Bandwidth 

Frame Relay 
Bandwidth 

msec 

bytes 

bytes 

kbps 

kbps 

kbps 

G.711 

64kbps 

10 

80 

120 

116.8 

97.6 

103.2 

20 

160 

200 

90.4 

80.8 

83.6 

30 

240 

280 

81.6 

75.2 

77.1 

G.729 

8kbps 

10 

10 

50 

60.8 

41.6 

47.2 

20 

20 

60 

34.4 

24.8 

27.6 

30 

30 

70 

25.6 

19.2 

21.1 

G.723.1 

6.3 kbps 

30 

24 

64 

24.0 

17.6 

19.5 

G.723.1 
5.3kbps 

30 

20 

60 

22.9 

16.5 

18.4 


Notes: 

1 Gray background indicates payload sizes used by BCM for transmission. Other values indicate payload 


sizes that BCM can receive. 

~ Ethernet includes the 14-byte Ethernet frame overhead plus a 12-bvte inter-frame gap. _ 

Table 1: Voice over IP transmission characteristics for unidirectional continuous media stream 


Trunk or Line Side Application 

There are several different deployment scenarios that may 
include deployment of IP terminals only, IP trunking or IP 
terminals with IP trunking. The deployment of IP terminals 
will focus on a LAN assessment to insure a successful 
deployment. In a scenario with IP trunking only, the focus of 
the assessment will be on the WAN. 

The most complex of scenarios includes IP terminals with IP 
trunking. This scenario illustrates a Meridian 1 with ITG line 
and trunk. Consideration with respect to equipment delay 
impairments must be taken into account when designing this 
type of solution. (Refer to Figure 1) 
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The current solution addresses QoS with two methods: 

For traffic traversing the WAN utilizing BayRS, we can 
implement protocol prioritization, traffic shaping (for Frame 
Relay), DiffServ and the MTU (Maximum Transmit Unit) 
size of IP packets transported over the WAN, larger packet 
sizes incur higher serialization delays and introduce jitter 
into the VoIP stream. CSE1000, BCM and Meridian 1 IE 
can implement DiffServ to provide QoS for VoIP traffic. 


In Frame Relay environments, BCM will mark packets DE 
(Discard Eligible) that are not in the Premium queue. The 
ITG Line card for the Meridian 1 and CSE 1000 can mark 
the DiffServ codepoint (DSCP) for both the media stream 
and signaling. Upon configuration of the DSP profile for the 
card, the DSCP marking is configured and downloaded to 
the card, upon boot the card will also send the new 
parameters to the assigned i2004 or i2050 terminals where 
the terminal will also set the DSCP. If we consider the link 
speed and packet size, we can predict the serialization delay 
introduced. Refer to Figure 2. 


Serialization transmission delay in msec, for different iink speeds 


Packet Size 


in Kbps 

40 bytes 

80 bytes 

88 bytes 136 bytes 184 bytes 232 bytes 280 bytes 


1.48K bytes 

56 

5.714 

11.429 


1 



64 

5.000 

10.000 

11.000 






128 

2.500 

5.000 

5.500 

8.500 

11-500 m 





256 

1.250 

2.500 

2.750 

4.250 

5.750 

7.250 

8.750 

cvtaf-v. «. fc-t- j-r 

y ■' -yj 


384 

0.833 

1.667 

1.833 

2.833 

3.833 

4.833 

5.833 

10.833 

hi- t-VaS'i-tU. 

SakfiJ&iTT--- at* . 

1000 

0.320 

0.640 

0.704 

1.088 

1.472 

1.856 

2.240 

4.160 

8.192 

11.840 

1540 

0.208 

0.416 

0.457 

0.706 

0.956 

1.205 

1.455 

2.701 

5.319 

7.688 

2048 

0.156 

0.313 

0.344 

0.531 

0.719 

0.906 

1.094 

2.031 

4.000 

5.781 

10000 

0.032 

0.064 

0.070 

0.109 

0.147 

0.186 

0.224 

0.416 

0.819 

1.184 

100000 

0.003 

0.006 

0.007 

0.011 

0.015 

0.019 

0.022 

0.042 

0.082 

0.118 

150000 

BOBOS 

0.004 

0.005 

0.007 

0.010 

0.012 

0.015 

0.028 

0.055 

0.079 


Figure 2: Serialization delay characteristics in ms for a given packet size and link speed 


RECOMMENDATION: Begin with an MTU size of 
232 bytes for connections less than 1Mbps adjusting 
upwards as needed. Some applications do not perform 
well with an adjusted MTU, so caution must be used 
when adjusting the MTU._ 


Link Types 

Today, a typical LAN has 100Mbps to the desktop and 
multi-Gigabit riser links in the switches. With this 
abundance of bandwidth, the potential issue is with peak link 
utilization (no averages allowed here). At a minimum. 

Layer 2 switching is required. 

PPP 

PPP links will typically give the network operator the most 
control for QoS as they are direct point-to-point links and 
provide dedicated bandwidth. Building a meshed topology 
is generally more costly with these types of links but do 
afford the designer more flexibility where the links terminate 
once the network is in place. 

Frame Relay 

Frame Relay gives the network operator much more 
flexibility when the requirements include a fully meshed 
topology. A fully meshed Frame Relay network has a lower 


overall cost than a fully meshed private line network. The 
challenge with Frame Relay is, these types ofjietworks are 
based on a publicly shared model with DLCl (Data Link 
Connection Identifier) numbers used to define PVC’s 
(Permanent Virtual Circuit) in the network. 

QoS in a Frame Relay network is achieved today by 
specifying a committed information rate (CIR) and using 
separate PVC's. The CIR on the PVC associated with the 
voice traffic must be configured for the total peak traffic 
because any traffic that exceeds the CIR will be marked 
discard eligible (DE) and may be dropped by the Frame 
Relay provider's network. This is not an acceptable 
condition for VoIP traffic since you cannot retransmit real 
time data carrying packetized voice. 

In these types of conditions, it is important to understand the 
design of the Frame Relay provider's network, how much 
traffic they are currently transporting and if they offer any 
type of service level agreement (SLA) in addition to the 
CIR. 

The WAN access platform in the customer's network can 
also help ensure that VoIP traffic does not exceed the CIR 
on the PVC. Protocol prioritization, traffic shaping and IP 
fragmentation (MTU) can insure that the VoIP traffic is 
treated properly and will not exceed the CIR on the PVC. 
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ATM 

ATM transport offers the possibility of providing a constant 
bit rate (CBR) service dedicating a channel with a fixed 
bandwidth based on the needs of the application. One 
consideration, when using ATM as a transport for VoIP, is 
the added overhead associated with ATM. A G.711 20ms 
voice payload, plus associated TCP, UDP and RTP header 
information, becomes a 200-byte frame. Therefore, using 
ATM as a transport requires the frame to be fragmented to 
fit into multiple cells and adds an additional 10-15% of 
overhead. G.729 significantly reduces the frame size to 60 
bytes, so CODEC selection is crucial for the WAN. 

RECOMMENDATION: Use G.711 for LAN based 
applications and G.729 for calls traversing the WAN. 
CODEC selection is based on overall objectives and cost 
targets for the VoIP deployment, __ 

Assess link utilization (3) 

Assessing link utilization is key to supporting VoIP over 
WAN links. There are several methods ot gathering 
statistical information on a WAN link, tools such as an 
existing network management system should have the ability 
to poll routers via SNMP and collect the statistics over a 
period of time to see what the utilization of a given WAN 
link is. If you do not have access to a network management 
system that can provide the above functionality, you can use 
the Multi-Router Traffic Grapher a free tool available under 
the GNU General Public License, MRTG is based on PERL 
and C and works under UNIX and Windows NT. It also 
requires a web server as the underlying access engine. The 
MRTG polls SNMP MIB variables on the device, collects 
them and presents them in graphical and numerical format. 

You can access more information on MRTG at 
www.mrtg.org . Other methods of assessment include the use 
of imbedded RMON and external RMON probes installed 
for the purpose of gathering statistical information that 
includes link utilization. 


RECOMMENDATION: On connections less than 
1,5Mbps, do not exceed 50% peak loading. Connections 
1,5Mbps and above can be loaded up to 80% peak._ 

Assess peak delay and packet loss (3a) 

Consistent voice quality is dependent on several factors, 
peak delay times over a given link and packet loss. Peak 
delay can be measured with tools such as Qcheck and 
Chariot from NetIQ. It is best to perform a long-term 
analysis and have a larger sample of the delay and packet 
loss on the network. 


RECOMMENDATION: One-way delay should not 
exceed 150ms and packet loss should be less than 0.5%. 


LAN and WAN Platforms (4) 

After determining the topology of the customers network the 
next step is to evaluate the LAN and WAN platforms 
installed in the network. Shared media on the LAN is an 
unsupported scenario so, if the customer has shared media 
on their LAN the first goal is to install layer 2 switching as a 
minimum requirement. If there is a L2 switched edge with 
L3 core we need to assess the capabilities of the network 
from a bandwidth perspective. 

LAN Scenario 

Many of today’s networks are designed with high bandwidth 
edge switches with multi-gigabit Ethernet connections to a 
layer 3-switched core. These types of networks are the best- 
case scenario and generally only require a tew simple tests 
with an active monitoring tool that can ascertain the delay 
and packet loss on the network. 

Some of the most critical areas we must be concerned with 
are the riser access links and core capacity, if the desktop 
switching platform provides 24 connections and are 
100Mbps with only 4 MLT 100Mbps links, there is a 
significant bottleneck at the riser where serialization and 
queuing delays can become an issue so, the need for QoS 
mechanisms such as 802.1Q/p and/or DiffServ become a 
necessity. Another approach is migrating the 100Mbps riser 
links to gigabit Ethernet. 

WAN Scenario 

The WAN is typically the most challenging to guarantee 
consistent application performance and has many different 
scenarios each presenting unique challenges. In a Frame 
Relay environment, a typical design may have many low- 
speed links terminating at branch locations with a single 
high-speed link into a hub location. (See Figure 3) 



This scenario presents an interesting challenge where the 
remote site with a low speed link can be overrun by traffic 
from the central site with a larger bandwidth connection. 
BayRS devices can mitigate this problem with traffic 
shaping, priority queuing. The use of separate PVC’s for 
voice and data between the central site and remote branch 
can also help mitigate the problem. 

What form(s) of QoS do the currently installed 
platforms support? (4a) 

In order to insure consistent voice quality, some torm ot 
quality of service must be supported on the platforms 
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expected to transport VoIP. There are several methods to 
provide QoS, such as high bandwidth, packet classification, 
DiffServ, IP fragmentation, traffic shaping and the use of the 
platforms queuing mechanisms. 

BCM and the ITG trunk implement a QoS active monitor 
that pings the far-end gateways it is connected to and 
maintains a history of results, upon the request of a trunk 
resource the BCM or ITG-T will admit the call only if the 
criteria (based on the G.107 E-Model) set by the 
administrator is met. 

The ITG line card has the ability to create bandwidth zones 
based on available bandwidth and CODEC negotiation. A 
call between low bandwidth/low bandwidth and low/high 
bandwidth can negotiate G.729 (for example) and in a 
high/high bandwidth call, use G.711. 

High Bandwidth 

LAN/Campus networks designed with 100Mbps to the 
desk, high performance closet switching with devices like 
the BPS 2000 connected to the core network with multi-gig 
riser connections with devices like the Passport 8600 in the 
core may only have a minimal requirement for QoS, these 
types of devices can take advantage of DiffServ from end to 
end if necessary, and if the VoIP traffic will traverse the 
WAN, high bandwidth may be achieved with networks 
connected via high speed point to point DS3 links or 
possibly, ATM/SONET services of OC-3 and higher. 

Another possibility is an all-optical network with gigabit 
Ethernet used as transport. While these types of networks 
exist in many metropolitan areas across North America, 
many enterprise networks are built with lower speed point to 
point and Frame Relay services, we will address the various 
QoS mechanisms and how they fit together to create a 
reliable, predictable VoIP implementation. 

Layer 2 CoS 

CoS (Class of Service) at layer 2 is achieved with 802.IQ 
VLAN tagging and 802.IP prioritization. In a scenario 
where the edge switches in the LAN only support layer 2 
CoS, IP terminals can be directly connected to a switch port 
that is assigned to a VLAN for IP Terminals and prioritized 
via 802.IP (class selector 5). Layer 2 CoS is dependent on 
deploying VLANs that span the entire network as 802.1P is 
implemented with VLAN tagging (802.IQ). This type of 
implementation can become very complex, as every device 
in the network must have a common VLAN defined. 

Layer 3 QoS 

Layer 3 QoS is achieved via DiffServ (RFC 2474) and tor 
VoIP traffic the EF (Expedited Forwarding) Per Hop 
Behavior (RFC 2598) is the preference for classification of 
packets at layer 3. In order for DiffServ to be implemented 
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from end -to-end, every device that will transport VoIP 
traffic must provide support for DiffServ. It is up to the end 
point to mark the VoIP packets upon egress where the 
network devices that transport the VoIP traffic will then 
observe the L3 marking and place the marked traffic in a 
high priority queue in the device. 

DiffServ can be managed from a central location via a policy 
server where the network administrator defines a service 
class (priority) for a traffic type (VoIP). Optivity Policy 
Server and Optivity Network Configuration System can 
provide this for devices that implement COPS-PR capability. 
BCM 2.5 and BayRS devices have the ability to 
communicate with policy servers via COPS-PR. 

Typically devices that implement layer 3 DiffServ can map 
802.IP marked traffic into a predefined DiffServ queue. This 
gives the network designer some added flexibility and 
allows hybrid L2 CoS and L3 DiffServ implementations. 

What protocols are in use? (5) 

When assessing the network for VoIP readiness, do not 
overlook the distribution of protocols in the network, 
specifically on the WAN. Tools available for this task 
include NMS systems that can poll devices via SNMP as 
well as RMON probes. 

If there are protocols in use other than IP and implement 
MTU, we will still have other protocols that maintain larger 
frame sizes and can introduce additional delay to the VoIP 
traffic. You must also pay strict attention to certain 
applications running over IP that may set the frames with the 
“may fragment” bit set to 1 which not allow fragmentation 
so, as part of the overall assessment process Sniffer traces on 
the LAN will determine if there are any applications that 
have this bit set. 

Another important consideration is the use of firewalls and 
NAT (Network Address Translation) and a secure VPN 
(Virtual Private Network) access via IPSec encryption. The 
requirement to deploy IP terminals in a remote environment 
(work at home users) with connections to the public Internet 
via xDSL and cable modem may have routers that 
implement NAT and IPSec. These connections would 
traverse the public Internet utilizing IPSec encryption and 
may need to cross a firewall connection as well. The 
network designer must also consider the security policy in 
force and check to see if the ports required for VoIP can be 
allowed to traverse the firewall. 

What routing protocols are in use? (5a) 

Routing protocols in the WAN can be very important when 
considering how VoIP calls will be routed and how quickly 
fail-over occurs. When planning deployment of VoIP, the 
network designer must be aware of what types ot situations 
trigger a routing table update with respect to the routing 
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protocol. This will help when predicting what path a VoIP 
flow may take upon a failure in the network. 

The time it takes a network to re-converge after a link failure 
must also be considered as the process may take several 
minutes depending on the size of the network and routing 
protocol in use. Routing protocols in the LAN must also be 
considered and when deploying IP terminals with the CSE 
1000, Meridian 1 with ITG line card or BCM with similar 
consequences. 

Where are the traffic flows in the network? (6) 

Traffic flows in the network must be identified by utilizing 
an existing NMS (Network Management System) or use of 
other passive tools such as Sniffer Pro that can identify 
flows between devices as well as protocol distribution in the 
network. RMON (Remote Monitoring) probes and devices 
with imbedded RMON capability can also help the network 
designer determine where flows occur in the network. 

Once traffic flows are identified, the process of determining 
bandwidth requirements can begin with tools such as the 
VoIP bandwidth calculator. These flows must be 
characterized over a period of time (a week or longer 
depending on the complexity of the network). We must look 
at peak times of day, week, and month to determine where 
the highest utilization exists. 

Is Call Detail Record available? (6a) 

Obtaining a call detail record is important to ascertain where 
the VoIP traffic flows will be in the network. The call detail 
record will assist in determining where VoIP flows will 
ultimately be in the network. The peak values for time of 
day and day of week/month must be considered to ensure 
consistent voice quality. 

What is the expected voice quality? (7) 

In addition to providing predictable performance for VoIP, 
voice quality is the most subjective test of success of a VoIP 
deployment. Once the measurements of the network are 
obtained we can use calculations based on the T1A/EIA 
G. 107 E-Model to predict the obtainable quality over a given 
link. Using formulas such as the E-Model are important, as 
traditional models such as MOS (Mean Opinion Score) are 
not applicable in VoIP networks as they assume the network 
is TDM based. 

MOS scores and the R rating (7a) 

Once you have determined what the expected voice quality 
is, examples such as PSTN, mobile phone, international long 
distance. We can then map the expected quality to a MOS 
score and use it to calculate the R-value derived from the 
ITU G.107 E-Model. 


Summary 

Planning for a successful deployment of VoIP begins with 
the process outlined in this document. The questions are 
intended to help the network designer and raise awareness of 
the many areas that must be considered when deploying 
VoIP and what additional steps may be required to deploy. 

Tools 

• Sniffer Pro - A real time passive network monitoring 
and troubleshooting tool. Decodes more than 400 
protocols and is an important tool for the network 
designer and engineer. httn://www.sniffer.com/ 

• NetlQ Chariot - Active monitoring tool that tests 
network equipment by generating application layer 
traffic and measuring performance. By generating 
traffic that looks like real user traffic Chariot also 
predicts the performance of networked applications and 
the impact of network changes, such as adding more 
users or rolling out a new technology. 

http: ; www.netia.com/Products/Network Performance/ 
Chariot/Default.asp 

• NetlQ Qcheck - A freeware tool from NetlQ to gather 
performance parameters over a short period of time. 
http://wwvw.netia.com/acheck/default.asp 

• Multi Router Traffic Grapher - A tool that can be 
implemented quickly to monitor any number of network 
devices via SNMP, http://www.mrtg.org 
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Introduction 

This document describes the bandwidth and packet delay challenges for supporting voice communications over IP networks. 
Bandwidth requirements are presented for G.711 and G.729 as example of standard voice coding and voice codecs offering 
significant compression. Packet delay, delay variation (jitter) and packet loss are described along with the technologies used to 
improve QoS. While the codecs and network examples presented in this application note are from voice over IP wireline 
networks, it should be noted the underlying technological challenges and principles apply in general to all forms of packet voice 
networking. 

Recommendations are presented to provide guidelines for product deployment. The guidelines and examples are intended only as 
an introduction to the topics discussed. They are not intended as a network traffic-engineering tool because the performance 
characteristic of the underlying packet network will dictate specific deployment requirements (such as codec selection to match 
network bandwidth). 

Voice over IP Packetization Fundamentals 

To accurately convert an analog signal into a digital signal, the sampling rate must be at least twice the highest frequency of the 
signal. The narrowband frequency response of the PSTN is between 300 Hz and 4 kHz, so the sampling rate must be at least 8 
kbps (kilobits per second). As shown in Figure 1, the 8 kbps samples times the 8 bit coding resolution requires 64 kbps of 
bandwidth. In a data/voice network where the maximum available bandwidth might only be 64 kbps, the voice traffic could take- 
up all the bandwidth, allowing none for data traffic. Pulse Code Modulation (PCM) is the process of mapping discrete 8bit values 
to voice samples. PCM is the benchmark codec used by the PSTN (ITU G.711). 


Analog Digital 



Figure 1: Analog to Digital Conversion 

The bandwidth required is directly related to the voice sample size that is used. Table 1 shows examples of the bandwidth required 
for G.711 at various voice sample sizes. The smaller the voice sample (typically 10 to 40ms) the more packets that will be needed 
to support a voice call and the greater the impact of the packet header compared to the voice as IP packet payload. The following 
simple equation can be used to describe the network bandwidth required at the IP packet layer: 

IP Bandwidth = (Bytes of Voice Payload + IP header) x 8bits per byte x IP packets generated per second of voice 
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Codec 

- 

Voice content 
per IP packet 

IP packets 
generated for 

1 sec of voice 

The 

Math 

IP bytes 
required for 

1 sec of voice 

Effective 
bandwidth at 
IP layer* 

G.711 

5ms = 
40bytes 

200 

(40+40) 

x 200 = 

16,000 

128Kbps 

G.711 

10ms = 
80bytes 

100 

(80+40) 

x 100 = 

12,000 

96Kbps 

G.711 

20ms = 
160bytes 

50 

(160+40) 

x 50 = 

10,000 

80Kbps 


Table 1: Examples of Bandwidth Requirements for G.711 Transported over IP 

* Assumptions used: 

• IP packet header is 40 bytes 

• Does not address potential bandwidth savings from Voice Activity Detection 

• Bandwidth required is for each direction of call. 


Benefits of Speech Compression on Bandwidth Requirements 

Speech compression algorithms, such as G.729, are intended to reduce the bandwidth required. The term codec stands for 
"compression/decompression." A codec runs a compression algorithm, or specialized computer program, that reduces the number 
of bytes consumed in coding digital data to minimize bandwidth requirements relative to G.711 PCM voice. The concept is 
illustrated in Figure 2. The bandwidth freed up by speech compression can be used for data traffic or additional voice traffic. 

The trade-offs for minimizing bandwidth are delay and audible distortion. The Packet Delay and E-Model sections will address 
these issues. 


Codecs may be implemented in software, in hardware or in a software/hardware mix using Digital Signal Processors (DSP). 



Analog 

Voice 

A 


Compressed 
Digital 
T, Voice 

Available ! 

Bandwidth 


Figure 2: Speech Compression 

Using the same basic equation for calculating bandwidth required at the IP packet layer as previously described, the following 
table provides an example of bandwidth savings that can be achieved by G.729 speech compression: 
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Codec 

Voice content 
per IP packet 

IP packets 
generated for 

1 sec of voice 

The 

Math 

IP bytes 
required for 

1 sec of voice 

Effective 
bandwidth at 

IP layer 

G.729 

1 Frame 

10ms = 

10 bytes 

100 

(10+40) 

x 100 = 

5,000 

40Kbps 

G.729 

2 Frames 

2 x 10ms = 

20m s = 

20 bytes 

50 

(20+40) 

x 50 = 

3,000 

24Kbps 

G.729 

4 Frames 

4 x 10ms = 

40ms = 

40 bytes 

25 

(40+40) 

x 25 = 

2,000 

16Kbps 


Table 2: Examples of Bandwidth Requirements for G.729 Transported over IP 

VoIP Bandwidth Requirements for Ethernet, Frame Relay and ATM 
Networks 

In order to fully assess the impact that voice packetization has on network bandwidth requirements, the overhead of the Data Link 
Layer network technology transporting the IP packet (containing the voice payload) must be factored in. The analysis below 
addresses VoIP packets being transmitted over Ethernet, Frame Relay and ATM (AAL5) network links, representative of typical 
customer premise access networks. 

With the additional overhead understood for a specific network type (e.g. Ethernet, Frame Relay or ATM), the network bandwidth 
per voice call and the maximum number of calls supported at a given network link rate can be determined. 

Ethernet, Frame Relay and ATM Packet Formats 

Examples of packetization formats are provided for G.711 (Figure 3) and G.729 (Figure 4) with 20ms voice samples. With this 
information, per call bandwidth requirements for these codecs can be calculated and used to determine the number of voice calls 
supported at typical Ethernet, Frame Relay and ATM network link speeds. 
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Figure 3: G.711 Voice over IP (20ms voice sample) for Ethernet, Frame Relay and ATM networks 



Figure 4: G.729 VoIP (20ms voice sample) for Ethernet, Frame Relay and ATM networks* 
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,. . , ■ . the ner ca ii bandwidth requirements and the number of voice calls for typical Ethernet, Frame 

* See A PPen « . d ^ on voice codec (G.711 & G.729) and voice payload (10, 20 and 30 ms). Call capacities 

Staled are fer tilization of 50% of link bandwidth for voice traffic, showing comparison of codecs, payloads and network 

bandwidth. 

Benefit of IP Header Compression on Bandwidth Requirements 

, , . TP rnmnressirm creates a more linear relationship between voice sample and IP payload size 

wtthtsp"® rr™ required, so .he bundwid.h require! pe, call is no, dependent on the voice sample and IP payload 

size. 

71 , vojce samD ie si^es reviewed, bandwidth required per call and the same for ATM networks and vanes little for 
For all Ami This direct ] y impacts the maximum voice calls supported at each network link speed. When using IP 
header compression for 0711, packet delay will be the key, confuting factor affecting VoIP performance charactenstics. 

a u p- c same j s not true for G 729 due to the fact that the voice payload size and compressed header size are 

mueiTs ? Kc, there is a much stronger dependency on the number of IP packed tha, must be genera.ed fo, a gt.en dumtton 
rfspeech to, is being sampled and packe.ized, jus, at there is for the standard IP header calculahons. 


■ • JSS vo j ce bundles 


RTP Frame 


| RTP Header Voice Payload 


Destination 


UDP Datagram 

Sourci 


Length \q hecksum rjp Header Voice Payload j 


IP Packet Header- 


8 1 12 


20 


Preamble° Ur Source UDPHe ^" RTP Header Voice Payload j 


Compressed IP/UDP/RTP with 
ppp Header into Ethernet 


8 1616 l4 -|2| 


20 


Destination 802.1 q/p ppp 


\ N 

Compressed Vo j ce p ay | 0a d j 
Header 


Compressed IP/UDP/RTP with 
PPP Header into Frame Relay 



ppp Compressed voice Payload j Frame 


Payload 


Compressed IP/UDP/RTP with 20 IIKsI*— aals 

PPP Header into ATM (AAL5) L | “i T ™ ler 

ATM _pp Compressed voice Payload Padding 

_ Header Header Header _ 

Figure 5: G.729 VoIP (20ms voice sample) with Header Compression for Ethernet, Frame Relay and ATM networks* 

* Annenrlix R which shows the per call bandwidth requirements and the number of voice calls for typical Ethernet, Frame 
Relay S^n^rk ^s” pending on voice codec (G.711 & G.729) and voice payload (10. 20 and 30 ms). Cah capactes 
stated are for utilization of 50%oflink bandwidth for voice traffic, showing comparison of codecs, payloads and network 
bandwidth. 
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Header Compression Recommendations 


Compression of the IP, UDP, and RTP headers is an important part of providing QoS over bandwidth restrictive links for voic 
tratf . C RFC2507 - ‘IP Header Compression’ describes a method for compressing the IP header for ‘ordinary’ data such FTP, 

which can reduce the header overhead to approximately 1%. , , . 

. RFC 2508 - ‘Compressing IP/UDP/RTP Headers for Low-Speed Serial Links’ describes the method taking the combi 
IP/UDP/RTP header which totals 40 bytes and compressing down to 2 - 4 bytes. This is a significant saving when th 
typical RTP payload can be as low as 20 bytes. 

. RFC2509 - TP Header Compression over PPP’ describes the method of negotiating IP header compression over PPP as 

nart of IPCP, IP-Compression-Protocol. . , 

i . . nr-,ft q RDHC to be published as RFC3095 - ‘Robust Header Compression describes a highly robust and 

• Internet-Draft 9, K.vJHv^, p 0 x 0/1 ir\D/iP 1 idp/ip qnH F^P/IP headers 

efficient (40 bytes to 1 byte) header compression scheme for wireless RTP/UDP/1P, UDP/IP and hbF/lL headers. 

Combining these IP Header Compression techniques with PPP header optimization, you can effectively reduce the IP overhead 
relative to the small voice payload. 


Summary of Voice over IP Packetization Basics 

. Analysis of .he packetization of voice traffic over IP networks illnstta.es the bandwidth requirements fair call for 

npnlnrpwed and compressed voice. Bandwidth is dependent on voice payload content per IP packet 
w- P the bandwidth required per call, the maximum number of voice calls for a given link speed can be calculated. 

I IP header compression significantly reduces the bandwidth required per voice call by reducing the IP header overhead per 
packet. This afso increases the maximum number of voice calls supported at a given network link spee . 

Packet Delay 

, • r , mrv w nn the nerceived quality of a voice call and requires special consideration in deploying packet 

Packet delay has a voice QoS begins with the fundamental selection of a codec to meet a given customer 

voice networking D l P s i ’ 0 C n Zrithms vary in die voice impairment introduced), this application note focuses on the impact ot the 
(e.g. speech compression algorithms y processing fundamentals per se. (Although audio processing 

below.) £ie Figure 6 

delay, as well as those technologies that are used to counter these packet telephony challenges. _ 


Ingress Node 
Call Origination 

ir%® 

m* ' 


Egress Node 
Call Termination 



Codec encoding 
Packetization 
Ingress queuing 
Codec look ahead 


Packet Network 


Ingress link delay 
Backbone transmission 
Backbone queuing 
Egress link delay 
Propagation delay 



Egress queuing 
Jitter buffering 
Codec decoding 


Codec compression 

DifTServ EF / 802.1 p 
packet marking 

Payload multiplexing 

Call admission control 


IEEE 802.Ip LAN 
prioritization 

DiffServ IP network 
prioritization 


Jitter buffer 
Codec decoding 


Figure 6: Sources of Packet Delay 
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The total end-to-end delay characteristics of packet voice traffic occur in the following: 


Ingress node audio processing: 

Voice Coder Algorithmic Processing 
Voice Payload Packetization 

Fixed delay 
Fixed delay 

Ingress node packet queuing: 

Packet contention for network port 

Variable delay 

Data network transmission: 

LAN and WAN link speeds 
Propagation over network 

Packet contention at network nodes 

Fixed delay (per 
Fixed delay (per 
Variable delay 

Egress node packet queuing 

Packet contention for network port 
Packet jitter buffer 

Variable delay 
Variable delay 

Egress node audio processing 

Voice Decoder Processing 

Fixed delay 


network segment type) 
transmission distance) 


By outlining these parameters for a given packet voice network deployment, one can build a Delay Budget analysis to better 
manage QoS characteristics. Note that the outline above does not account for enhanced applications, such as packet encryption, 
which can add additional delay and should be included in a Delay Budget analysis if applied. 


Voice Packet Delay at the Ingress Node 

Voice Coding Algorithmic Processing and Packetization 

Delay imposed by voice coding is dependent on the algorithmic process of the codec selected. This includes definition of the 
underlying frame size and look-ahead processing (for compression algorithms). Voice payload packetization includes the not only 
the IP header packetization, but is a factor of the number of voice frames buffered prior to being grouped into a single data packet. 

An important consideration must be made in balancing between the desire to increase payload per packet in order to minimize 
bandwidth required and the inherent delay added when buffering this additional payload prior to and during transmission. 


Compression 

Method 


Look Ahead 

delay (ms) 

Algorithmic 

Delay (ms) 

G.711 

(PCM) 

.125* 

N/A 

.125 

G.729(a) 

(8K CS-ACELP) 

10 

5 


G.723.1 
(6.3K MPMLQ) 
(5.3K ACELP) 

30 

7.5 

37.5** 


Table 3: Voice Coder Algorithmic Processing 

* G.711 voice samples offer no true speech framing prior to packetization. 1 byte per 0.125ms sample = 8 bytes per lsecond of 
voice. In practice however, G.711 is framed in 10 or 20 ms increments depending on the trade-off of delay versus packet 
efficiency. Also note, that although G.711 does not include a Look Ahead, the use of an add-on, receive-end packet loss 
concealment (PLC) algorithm is desirable to mask the audible effects of short bursts of packet loss. The PLC adds approximately 5 
ms on the egress side. 

** G.723.1 is included as an example of more complex codec. Its high algorithmic delay is one reason G.729 is preferred for 
compression. 
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Ingress Node Packet Queuing Prior to Transmission 

Ingress nodes introduce jitter in multiservice applications due to the multiplexing of voice and data onto a single network link. 
Multiple packets can arrive from different sources at the same time and therefore must be queued prior to transmission. Figure 7 
illustrates how source jitter can be introduced when several voice streams (calls) are multiplexed on to a single packet link along 
with a larger data packet. 



Fragmentation of large data packets is an important mechanism in minimizing the delay introduced in the transmission of voice 
packets, which are inherently kept small to address the issue of packet transmission delay. 


Network Transmission Delay 

Delay Due to Network Link Transmission Rates 

Network transmission delay is defined by the basic time required to transmit a packet without the effect of queuing or routing. 
Delay is dependent on the network link speed and packet size (see Table 4). However, it should be noted that typical IP packet 
transmissions occur over multiple networks of differing characteristics (e.g. Ethernet, Frame Relay, DSL, ATM). 


Packet transmission delay for various link speeds (msec) 

Link Speed 

Packet Size (Bytes) 

(Kbps) 

64 

128 

256 

512 

1500 

64 

8.000 

16.000 

32.000 

64.000 

187.500 

128 

4.000 

8.000 

16.000 

32.000 

93750 

256 

2.000 

4.000 

8.000 

16.000 

46.875 

384 

1.333 

2.667 

5.333 

10.667 

31.250 

512 

1.000 

2.000 

4.000 

8.000 

23.438 

1540 

0.332 

0.665 

1.330 

2.660 

7.792 

2048 

0.250 

0.500 

1.000 

2.000 

5.859 

45000 

0.011 

0.023 

0.046 

0.091 

0.267 

150000 

0.003 

0.007 

0.014 

0.027 

0.080 


Table 4: Packet Transmission Delay for Various Link Speeds 


Network Transmission Propagation Delay over Distance 

This is the additional delay caused by transmission distance based on "the speed of light". 
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Voice Packet Delay at the Egress Node 

Jitter seen at the end of packet transmission at the egress node 

Jitter is in effect the total variable delay introduced during the end-to-end processing of packet voice traffic. The total delay 
depends on numerous factors, including packet contention during ingress queuing, network conditions (routing, transmission 
queuing, etc.), statistical multiplexer (routers & switches) performance under load, link speed, voice/data packet size and egress 
queue buffer size. 

The delay of VoIP packets can occur at several queuing points in consideration of end-to-end performance: 


• Multiplexing voice channels, such as in the ingress gateway 

• ingress node queuing onto network 

• Core network node queuing 

• Egress node queuing from network 

In order to control VoIP packet delay and jitter some form of call admission control (CAC) is required. CAC performs both 
admission and blocking ftmctions. VoIP packets are allowed (admitted) when the network can adequately support them and 
disallowed when the network cannot support them per the service level agreement between the subscriber and service provider. 

Jitter buffers can and should be sized independently of a packet size. Packet size does have a bearing on jitter. Source/destination 
jitter is affected by low-speed access links and to a lesser extent, packet size. However, network loading can have a significant 
effect if there is no CAC. 

High-speed networks can transmit packets in much shorter time than the unit time of voice packet represents. In this case, packet 
jitter is totally dependent on the size of the buffer in a router and the degree of congestion/loading in the router. Jitter is mostly 
dependent on multiplexer loading, which becomes asymptotic above 90% loading of output link speed. 

Jitter buffers, as shown in Figure 8, are designed to smooth out variable packet reception, but inherently add more delay. 


c>i 


t 


> 


Jitter Buffer 
At Egress Node 


Figure 8: Jitter Buffer 


Voice Decoder Processing 

Voice play out at the egress point results in a fixed delay due to codec decoding algorithmic processing. This will include any 
packet loss concealment mechanism inherent to specific codec used (e.g. G.729). 

Total Delay Budget 

Added together, the voice processing and packet network factors outlined above all contribute to the total voice packet delay. 
Figure 9 illustrates the process with typical ranges of delay values. For conversations, the rule of thumb is that one-way delay 
should be less than 150 ms. Figure 9 shows that delay can easily become an issue, and understanding the relative importance of 
the delay elements in any given customer application is important in determining what areas need to be changed, to minimize the 
impact on the total end-to-end delay. 
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Frame length Look ahead 



JMiMliui _. Total Delay Budget 
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w 
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Figure 9: Total Delay Budget 


Guidelines for Transmission Planning Using the E-model 

Once the delay budget profile has been outlined, probable voice quality characteristics can be assessed using industry standard 
guidelines. This section will summarize recommendations for maintaining acceptable voice quality using the ITU E-model. 

TIA/EIA TSB116, “Voice Quality Recommendations for IP Telephony” gives a comprehensive description of IP telephony 
impairments and shows how the E-Model can be used to predict the voice quality of a conversation. The material in this section 
was extracted from TSB116. 



Introduction to Voice Quality - E-model (ITU G.107) 

The E-Model is a transmission-planning tool for estimating the user satisfaction of a narrowband (300 to 3400 Hz), handset 
conversation, as perceived by the listener. It is defined in ITU G.107. The E-Model has proven to be versatile tool that has adapted 
well to the impairments of IP telephony. The output of the E-Model is a scalar called the “Rating Factor”, the “R-value”, or simply 
R. The scale is typically from 50 to 94, where everything below 50 is clearly unacceptable and everything above 94.15 (the 
maximum with the G. 107 E-Model, version 19 default values, at 0 ms) is unobtainable in narrowband telephony. 

R is calculate from a number of parameters like loudness, echo and delay, but it takes into account the effects of packet loss and 
speech compression codecs with a parameter called, Ie, the equipment impairment factor. This will be covered in more detail in 
the next section. 

Recommended IP Telephony Voice Quality Categories 

Figure 10 shows the “High”, “Medium” and “Low” Voice Quality Categories that have been agreed to in the standards community 
(TIA TR-41 and ETSI TIPHON) and how these categories map onto the R-scale. 
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that the existing wireline PSTN is a subset of the “High” category. The goods news for IP telephony is that more than 100ms still 
available in the “High” category. The bad news is that wireless technologies got there first and already use that 100ms. 

User Satisfaction 

100 ----- 

Very 

- _le = 0 Satisfactory 


Existing 

PSTN 


Satisfactory 


Some Users 
Dissatisfied 


Many Users 
Dissatisfied 


Exceptional”'' 
Limiting Case 


One-way Delay (ms) 

Figure 12: Existing PSTN Performance 

A Comparison of Speech Compression Impairment for G.711 and G.729A 

User Satisfaction 
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- __ j Satisfactory 


Satisfactory 


Some Users 
Dissatisfied 


G.729A 


Many Users 
Dissatisfied 


Exceptional"^ 
Limiting Case j 


One-way Delay (ms) 

Figure 13: G.729A Speech Compression Impairment compared to Uncompressed G.711 
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Figure 13 shows the effect of speech compression by comparing the performance of G.729A to G.711. G.729A has an Ie value of 
11, which has the effect of lowering the G.729A curve by 11 R on the Y-axis, relative to the G.711 curve. Think of the Y-axis as 
the distortion axis. Adding distortion means the one-way delay for a given R is reduced. For instance, at R = 70 the delay 
(including propagation delay) available to G.729A is about 80 ms less than G.711 and at R = 80 the delay available to G.729A is 
about 120 ms less than G.711. Speech compression means: more distortion, less available delay. 


Packetization and Jitter Buffer Delay 

Figure 14 shows the four components to delay: packetization, jitter buffer, transport and propagation. Physically, the packetization 
and jitter buffer delays are at the edges and the transport and propagation delays are in the middle. The legend refers to equations 
for minimum and maximum packetization delay and jitter buffer delay, which are detailed in TSB116. The example is for product 
using G.729A +VAD that has a 10ms speech frame size and 2 frames per packet (plus a look-ahead of 5ms). The worst-case 
situation is shown: maximum packetization delay for low-speed connections, where the compression/encoding process fully 
utilizes the power of the processor and the jitter buffer is frame-based. The delay would be less if the connection was high-speed, if 
the processor had more horsepower (the sufficient processor power case) and if the jitter buffer was an absolute buffer that was 
slightly bigger than the expected source jitter (delay variation). 

There is always a trade-off between header-to-payload efficiency and packetization delay, but as more speech frames and longer 
speech frames are inserted into each packet, the packetization delay increases. Jitter buffers solve the lost and late packet problem 
by adding delay that reduces the available delay budget. In summary, assuming the transport delay is fixed, increasing the 
packetization and jitter buffer delay reduces the available propagation delay for a given voice quality level or it reduces the voice 
quality level for a given amount of propagation delay. 

User Satisfaction 



One-Way Delay, T (ms) 



Maximum packetization delay + jitter for G.729A+VAD: Equation (2}+ Equation {5} 
(M = frame size / N = # of frames per packet) 



High Voice Quality 


Medium Voice Quality 



Low Voice Quality 


Figure 14: Components of Delay 
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Transcoding and Tandeming 

Transcoding occurs when a signal is encoded t wo or more times through different types of non-G.711 cod ecs, s eparated bv G.711 
or linear segments. For example: from GSM to G.711 to G/729A. The Ie values are additive. For example: le total = GSM (Ie=5) + 
"G7729A (Ie=l 1) = 5+11 = 16. The severity of the impairment depends on the Ie values of the codecs involved. Direct conversion 
between arbitrary codecs is not yet possible. A way around the additive impairment is by Transcoder Free Operation (TrFO). This 
out-of-band signaling procedure provides the capability of negotiating the same (or at least an interoperable) encoder/decoder 
combination between the end terminals, with no conversion to/from G.711 in between. In the above example, if GSM was 
negotiated at both ends then, le total = 5. TrFO is still in the discussion stage for wireless networks. It will be just as important for 
packet networks. 

Tandeming is similar in concept to transcoding, except it involves the same type of codec, whereas transcoding involves different 
types of codecs. In general, tandeming occurs when a signal is encoded two or more times through the same type of codecs, 
separated by analog segments or G.711 segments with digital processing. However, it is more complicated than that and it depends 
on the specific type of codec. In some cases, the Ie values are additive, in other cases they are not. See TIA/EIA TSB116 for a 
complete explanation. Tandem Free Operation (TFO) is an in-band signaling procedure to handshake between the transcoding 
units that would normally interface to the PSTN with G.711 PCM. Compared to TrFO the difference is that in TFO the end 
terminals are unaware of the TFO procedure. TFO was originally designed for wireless systems but it is also applicable to any 
packet network. From the E-Model point-of-view, just like TrFO, TFO uses a common codec, so the total Ie is the value for the 
single common codec. The TrFO example above, also applies to TFO. 

Effect of Packet Loss on Voice Quality 

Packet loss can also be thought of as distortion, but unlike speech compression distortion that is what-you-hear-doesn’t-quite- 
sound-like-what-they-said distortion, packet loss distortion ranges from mild clipping to major dropouts. As mentioned previously, 
the amount of packet loss depends on the link speed and the channel contention. In practice, intranet carriers and corporate 
managed IP networks design their networks for packet loss rates well below 1%, but low speed links may have packet loss rates 
above 5%. The problem is that most packet loss is bursty in nature, i.e., occasional long losses, rather than random, i.e., frequent 
short losses, but most of the published data is for random packet loss because it is easy to create. One implication of bursty packet 
loss is that packet loss performance is directly related to the packet size, i.e., the smaller the packet size, the better the loss 
performance. This is the opposite conclusion from the efficiency section presented earlier. Codecs designed for packet networks, 
like G.729A, have built-in packet loss concealment (PLC) algorithms. Others that were designed for TDM networks, like G.711, 
require add-on PLCs when used in packet networks. PLCs can recover up to about 40 ms of loss speech at the expense of adding 
some fixed delay. Figure 15 shows a family of curves on how G.729A reacts to random packet loss. 
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Other Considerations 

The above information on transmission planning assumes that the loss plan and telephone set loudness ratings are correct and that 
there is sufficient echo control. The following is a list of related standards that have been put in place to deal with these issues: 

• ANSI/TIA/ElA-810-A (2001) - "Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital 
Wireline Telephones" 

• TIA/EIA/TSB122-A (2001) - "Voice Gateway Loss and Level Plan Guidelines" 

• ITU-T Recommendation G. 168 (04/97) - "Digital network echo cancellers" 


Recommendations 

The following recommendations are a subset of the recommendations presented in TIA/EIA TSB116. These are general 
guidelines, not rules that concentrate on achieving the best possible performance, without consideration to cost, available 
technology or customer requirements. It is advisable to use the E-Model to verify that system will meet customer expectations. 
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Packet Delay 

#1: 

Use G.711 end-to-end because it has the lowest Ie-value and therefore it allows more delay for a given voice quality level. 

#2: 

Minimize the speech frame size and the number of speech frames per packet. 

#3: 

Actively minimize jitter buffer delay. 

#4: 

Actively minimize one-way delay. 

#5: 

Accept the E-Model results, which permit longer delays for low Ie-value codecs, like G.711, for a given R-value. 

#6: 

Use priority scheduling for voice-class traffic, as well as RTP header compression and data packet fragmentation on slow- 
speed links to minimize the contribution of this variable delay source. 

#7: 

Avoid using slow serial links 

Speech Compression 

#1: 

Use G.711 unless the link speed demands compression. 

#2: 

Speech compression codecs for wireless networks and packet networks must be rationalized to minimize transcoding 
issues. 

Packet Loss 

#1: 

Keep packet loss well below 1%. 

#2: 

Use packet loss concealment with G.711. 

#3: 

If other codecs are used, then use codecs that have built-in or add-on PLCs. 

#4: 

New PLCs should be optimized for less than 1% of packet loss. 

Speech Transcoding 

#1: 

Avoid transcoding where possible. Adds Ie and delay impairment. 

#2: 

For interoperability, IP gateways must support wireless codecs or IP must implement unified Transcoder Free Operation 
with wireless. 

Speech Tandeming 

#1: 

Avoid asynchronous tandeming where possible. Adds Ie and delay impairment. 


References 
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Appendix A 

Bandwidth Requirements Per Call and Maximum Number of Voice Calls Depending on Voice Codec, Voice Payload and Link 
Speed for Ethernet, Frame Relay and ATM Networks 
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Appendix B 

Effect of IP Header Compression on Bandwidth Requirements Per Call and Maximum Number of Voice Calls 


Bandwidth per Voice Calls with IP Header Compression 
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Welcome 

Course 0365 


Voice over Internet Protocol 
Technologies 


Audience 

- Sales or System Engineers, Technical Support Specialists, and 
Installation Specialists with a working knowledge of voice and 
data who need the fundamentals of Voice over Internet Protocol 
(VoIP) technologies, including: 

- Voice packetization 

- Packet telephony design issues 

- Traffic convergence issues 

- VoIP standardization and protocols 

- Network assessment 
Background 

- Designed to to help participants prepare to take the Nortel 
Networks 801 VoIP Technology Exam (Number: 921-801) 
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Objectives 


• Describe how to packetize voice using voice packet 
analysis, compression standards. Real Time Protocol 
(RTP), and User Datagram Protocol (UDP) 

• Explain and differentiate between the major components 
of Voice over Internet Protocol (VoIP) 

• Define voice quality on a data network, including the 
performance of speech CODECs, delay, echo impairment 
and control, and packet loss 

• Given required voice CODEC, voice payload, and link 
speed, calculate the bandwidth requirements for VoIP 
network engineering 

• Describe the common models for voice quality, including 
E-Model G.107 and Mean Opinion Score (MOS) 
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Objectives - Continued 


Define methods available for implementing QoS including 
Resource Reservation Protocol (IS/RSVP) Approach, 
Differentiated Services (DiffServ) Approach, and Ethernet 
802 standards 

Identify the challenges of low speed Wide Area Network 
(WAN) connections focusing on serialization delay and 
Maximum Transmission Unit (MTU) 

1 Define the network infrastructure, including the LANA/VAN 
environment and Security issues 
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Packet Telephony 
Overview 

Voice over Internet Protocol 
Technologies 



Objectives 


• Calculate overhead 

• Compare and contrast VoIP packet-switching models 

• Calculate bandwidth in milliseconds (ms) 

• Identify why RTP is idea! for handling packetized 
voice in an IP telephony environment 

• Compare UDP and TCP 
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Voice Packetization 


• CODECs: Coders and Decoders 



Sample Rate: Analog signal is sampled at a rate 
of 8 kHz per second 
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CODEC Selection 

• G.711 64 Kbps PCM 

• G.729 8 Kbps CS-ACELP 

• G.726 16, 24, 32, 40 ADPCM 

• G.723.1 6.3 Kbps MPMLQ 

5.38 Kbps CS-ACELP 



Bandwidth requirements are estimates. 
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How Overhead Impacts Packet 
Size 
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Comparing Packet-Switching 
Models 

• VoIP 

- Layer 3 LAN/WAN protocol 

- Variable packet sizes 

• VoFR 

- Layer 2 WAN protocol 

- Variable frame sizes 

•VoATM 

- Layer 2 LANA/VAN protocol 

- Fixed cell sizes 
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Calculating Bandwidth for 
Different Compression Standards 


(Bytes of Voice Payload + IP header) 
x IP packets generated per second of voice 
x 8 bits per byte 
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- CODEC G.729 = 8 Kbps 

-Voice payload (sample) = 10 ms (10 bytes) 

-IP header = 40 bytes 

- Link type = PPP 8 bytes 

- IP packets per second = 100 

. 

The math: 

(10 + 48) x 8 x 100 = 46,400 (46.4 Kbps) 
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Benchmarks: 


■ 
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5 Persort-to-Person (excellent) 

4 Phone quality (good) 

3 Adequately understandable 

but not very good quality (fair) 

2 Can understand words but cannot recognize speaker 
(poor) 

1 Cannot understand words or recognize speaker (bad) 
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E-Model 


• Enable us to relate both subjective and objective 
metrics while handling IP Telephony impairments 



R Value 
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Basic equation for E-Model 


R = Ro - Is - Id - le + A 


Where: 

. RO = 

• Is = 

. Id = 

• le ■ 


Base R-Value, such as noise 
Impairments that are simultaneous to speech, 
such as echo 

Impairments that are delayed after speech 
Impairments due to the effects of special 
equipment, such as CODECs 
Advantage factor (to take account of user advantages, 
such as mobility) 
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I Objectives 


Discriminate between various methods available for 
implementing QoS 

Explain issues and challenges of running VoIP over 
low speed WAN connections 

Define key infrastructure needed to support VoIP 
traffic in LAN and WAN environments 

Identify common Ethernet network issues for VoIP 
traffic in LAN environment 
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Factors that Impact QoS 


• Broad range of technologies, architecture, and 
protocols 

• Largely depends on jitter, delay, and packet loss 
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Resource Reservation Protocol 



(RSVP) 


• Reserves resources across network 

• Allocates requests on first-come, first-served basis 


Methods to Achieve QoS 

• Resource Reservation Protocol (RSVP) 

• Differentiated Services (DiffServ) 

• Ethernet 802 Standards 

• Port-Based Prioritization 

• Traffic Separation 

• IP Address Prioritization 

• Packet Fragmentation 
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Differentiated Services (DiffServ) 


Defines packets treatment across network 

- Referred to as Per Hop Behavior (PHB) treatment 

Specifies and controls network traffic by class 
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Port-Based Prioritization 


Protocols and Guidelines 





• Effective method to achieve optimal voice quality 


• Protocols: 

• Ability to prioritizes all traffic coming from specific 
port of Ethernet Layer 2 switch 


- Products can use UDP port ranges to provide high priority 
to VoIP packets 

- 802.1 p not required 


• Guidelines: 

- Backbone routers reserve more ports than edge routers 

- Port ranges on edge routers are a subset of backbone 



router port ranges 

Not recommended for IP terminals 


-Two ports must be reserved for each call expected to be 
carried over WAN link 
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> • Optional technique 

- Enables you to place all voice traffic onto one VLAN and all 
P other data traffic on another VLAN 


• Benefits : 

- Ensures voice QoS by allowing voice VLAN traffic to have a 
higher priority over the data VLAN traffic 

- Provides an easy way to connect a VoIP gateway from an 
IP-enabled switch to the company’s existing Ethernet Layer 
2 switch using only Layer 2 technology 

• Caution: Not all vendors recommend use of VLANs 
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Packet Fragmentation 


In mixed voice and data IP networks, must 
fragmented packets prior to traversing bandwidth- 
limited (less than 1 Mbps) connections to minimize 
voice delay and jitter 

Different protocols can perform fragmentation 

-ATM (automatic), Frame Relay (FRF.12), PPP, IP, PPP 


Allow protocol to perform 
fragmentation 


IP Address Prioritization 



• VoIP traffic can also be prioritized by its IP address 

• Ideal for devices with static IP addresses that rarely, 
if ever, change 

• Network administrator can configure the routers to 
filter (classify) and prioritize ail packets originating 
from these IP addresses and know they are from VoIP 
devices 
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IP Fragmentation (Maximum 
Transmission Unit) 


Most routers use a default maximum packet size of 
1500 bytes, which can take a considerable amount of 
time to transmit over a low bandwidth connection 

Data packets use up almost all of the delay budget 
for the voice traffic before the first voice packet is 
ever transmitted 

1 Reducing the MTU can put more data on the WAN 
sooner and is not necessarily as efficient 
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Example 

• High-speed link terminating in low-speed links 

• Traffic shaping will ensure no loss of packets from 
big pipe to little pipe 


== DS3 


256k Frac T 1 


Evaluating Customer Routers 


■ Three factors that influence 
router performance: 

- Baseline speed 

- Characteristics of routed traffic 

- External events 
(besides routed traffic) 
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Security Issues 


Firewalls 

Network Address Translations 
(NATs) 

Encryption 
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Common Ethernet Network Issues 
for LAN Environment 

• Bandwidth 

- Requires 10/100 Ethernet switching 

• Delay 

- Should less than 200 ms 

• Congestion 

-TCP-based Internet traffic can cause significant voice 
quality problems if QoS is not applied 

- Never use shared-media Ethernet hubs 
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LAN Environment - continued 





• Collision 

-Collisions occur more frequently as utilization levels 
increase 

- Layer 2 switching is required at a minimum to avoid collision 

• Packet Reordering 

- Packets take different paths and arrive out of order 
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VoIP Standardization and 
Signaling Protocols 

Voice over Internet Protocol 
Technologies 
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Objectives 


Standards, Recommendations and 
RFCs 


List organizations instrumental in defining and 
developing VoIP standards 

Identify role H.323 plays within VoIP network 

■ Apply H.323 standards during call setup 
1 Identify SIP in IP Telephony 

• Recognize role of SIP in supporting multimedia 
sessions with IP Telephony 

■ Differentiate between SIP and H.323 

• Identify other standards that support VoIP 
communications 
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1 Basis of a network: Allow equipment and 
applications to transport, recognize, process and 
respond to user requests for information 

• Advantages of standards 

- Interoperability 
-Competition 

- Ready market 
-Obsolete technology 
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Standards, Recommendations and^^^ 
RFCs - continued 

• Recommendation 

- Generally become network standards as accepted and 
implemented by manufacturers, providers, and suppliers 

• Request for Comment (RFC) 

- Can range from an official standardized protocol 
specification 

-Research results 

- Informational only 

• Other processes 


Standards Organizations 


• American National Standards Institute (ANSI) 

• International Standards Organization (ISO) 

• International Telecommunications Union (ITU) 

• European Telecommunications Standards Institute (ETSI) 

• Institute of Electrical & Electronic Engineers (IEEE) 

• Electronic Industries Alliance (EIA) 

• Information Infrastructure Standards Panel (MSP) 

• Telecommunications Industry Association (TIA) 

• Internet Engineering Task Force (IETF) 
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ITU Home Page 
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Specific ITU committees 

-ITU-D: Telecom Development 
- ITU-R: Radiocommunication Sector 
-ITU-T: Telecom Standardization 

1 15 Study Groups prepare recommendations for 
standards 
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IETF Home Page 







Specific IETF organizations 

-Internet Engineering Steering Group (IESG) 
-Internet Architecture Board (IAB) 

Working Groups 

-Over 100 
- Based on topics 
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Signaling Protocols 


Utilized to initiate and control communications 


• Dependent on the type of communications and 
applications involved 


• Types of protocols 

- H.323 

-Session Initiation Protocol (SIP) 

-Media Gateway Control Protocol (MGCP) 
— MEGACO/H.248 
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• Suite of protocols 

• Provides a foundation for audio, video, and data 
communications across IP-based networks 

• Network, platform, and application independent 

• Does not provide a guaranteed QoS 

• Supports 

- Stand-alone devices 

- Embedded personal computer technology 

- Point-to-point and multipoint conferencing 

• Addresses 

- Call control 

- Multimedia management 

- Bandwidth management 

- Interfaces between LANs and H.323 non-compliant endpoints 
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•G.XXX 
compression 
algorithms are 
existing ITU- 
standards 
incorporated 
into the H.323 
protocol suite 


Network 

Non-pi ar on reed 
bandwidth packet 
switched networks 

(Ethernet l 

Video 

H.26I 

H.2f»3 

Audio 

G.7I1 

G.722 

G.72X 

G.723 * 

G.72*» 

Multiplexing 

H.22S 

Control 

11.3*3 

Multipoint 

H.323 

Security 

H.323 

Data 

T 120 

( Ocnm. Interface 

TCP/IP 


DRTEL —-- 

NETWORKS' w wi . 


Pbq* ill of i«2 



• Incorporates support for various codecs or speech 
compression techniques for digitizing and 
compressing speech signals 

• Codecs affect 

- Speech quality 

- Bit rate 

-Computer power 
-Signal delay 
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H.323 V2 - continued 




• Supported codecs 

-G.711 
-G.722 
-G.728 
- G.723.1 
-G.729 
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H.323 Protocols 




















Interoperability of H.323 


• Defines methods for receiving client requests to 
communicate capabilities to send and establish 
common call setup and control protocols 

• Interoperability testing is sponsored by International 
Multimedia Teleconferencing Consortium (IMTC) 


Well-known Ports 


• Defined and tend to be reserved for frequently used 
higher level process with specific port numbers 
reserved 

- 25: SMTP 

- 80: Web 

- 110: POP 

-1718: Gatekeeper discovery 
-1719: Registration with the Gatekeeper 
-1720: H.225 destination 
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Session Initiation Protocol (SIP) 


SIP Architecture Overview 


• Designed to be scalable 

• Utilizes existing protocol tools 

• Interoperability is a key goal 

• Key functions 

- Supports interactive communications between users 

- Handles session initiation, termination, and modification 

- Describes session content through the use of Multipurpose 
Internet Mail Extensions (MIME) 

- Determines the location, or presence, of the user to initiate a 
session 

- Supports multicast, unicast, a mesh of unicast sessions or a 
combination of unicast and multicast 

- Supports mobile users 
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SIP Proxy Server SIP Proxy Server I 

Endpomt a Registrar % 

SIP Proxy Server 

SIP Redirect Server 
0 ^^ = ^*a_BegiStra r 


SIP Proxy Server 



SIP Proxy Server 
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j SIP Redirect Server I 
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SIP Requests 


SIP Response Types 


IBS 


INVITE 


CANCEL 

OPTIONS 

REGISTER 
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• Ixx Trying 

— 180 Ringing 

• 2xx Successful Connection 

• 3xx Redirection 

— 305 Use Proxy 

• 4xx Request Failure 

— 407 Proxy Authentication 

Required 

— 415 Unsupported Media 

Type 

— 483 Too Many Hops 

— 484 Address Incomplete 

— 486 Busy Here 

He 5J£Sc*KS 


5xx Server Failure 

- 502 Bad Gateway 

- 504 Gateway Time-out 

- 505 Version Not Supported 
6xx Global Failures 

- 600 Busy Everywhere 

- 603 Decline 


SIP Invite 


INVITE sip: arod@wta.com SIP/2.0 
Via: SIP/2.0/UOP msafin.atp.com 
From: Marat <sip:msafin@atp.com> 
To: Andy <siparod@wta.com> 


Cseq: 1 Invite 

Subject: Your tennis game 
Cont-Type: application/SDP 
V=0 

0=Marat 76329381938 IN IP4 192.168.3.2 


C-IN IP4 192.168.3.2 
M-audio 5004 RTP/AVP 0 12 18 


SIP URL of the called party 

Indicates path taken by the request 

Initiator of request 

Recipient of request 

Uniquely ID s a particular invitation 

Command Sequence - Uniquely ID s a 
request within a Call-lO 
Nature of the call 

Indicates the Media type in message 
Protocol version 
User, session ID, network type. 
Address 

Session name 
Connection info 

Media name, port address. Codec 
options available from client 


SIP and Mobility 


■ Supports Mobility 

-Terminal 
- Personal 

. Requires mobile hosts to inform home proxy servers 
of their new locations using the REGISTER procedure 

• In-progress mobile calls inform their home proxy 
servers of their constantly changing location through 
the REINVITE procedure 
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H.323 versus SIP 
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Networking community 


Ptov *led by Servers l Proxy 
Redirect. Registrar) 


Multimedia. multicast. telephony 


HJ23 


Telecom community (ITU) 


Stack. 


ASN.l 


Provided by Gatekeepers 


Intelligent 


Telephony 


V1 =TCP; V2=UDP 


Aliases 


H.323 versus SIP (cont’d) 


Service 

SIP 

HJ2J 

Call Hold 

Yes 

Yes 

Call Transfer 

Yes 

Yes 

Call Forward 

Yes 

Yes 

Call Waiting 

Yes 

Yes 

Thtrd-paty call 

Yes 

No 

Conference 

Yes 

Yes 

Click-to-dial 

Yes 

Yes 

Capability Exchange 

Yes 

Yes 


NO*TEl — 

N*rwo*o»> » 


HGRTEl —i.—*..1- 

NETWORKS' 


H.323 versus SIP - continued 


Interworking H.323/SIP 


tJrcS 


'all Setup Delay 


Packet l.m« Rec overy 


lamp Detection 


H.323 

Gatekeeper 



SIP Proxy/Redirect 
Server 


K 323 MCU yS internetworking 

H.323 Terminal Function 


SIP User Agent 
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Other Signaling Protocols 


Low-level device-control protocols that instruct a 
Media Gateway to merge streams coming from an 
external cell or packet network onto a cell or packet 
stream, such as RTP 

Provide call setup and clear voice or video calls in a 
packet network 

■ Signaling Protocols 

- Media Gateway Control Protocol (MGCP) 

- MEGACO/H.248 
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Gateway Protocol History 
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MEGACO Architecture Overview 




• IETF version of ITU H.248, from the H.323 standards protocol 
suite 

• Supports multimedia 

• Utilizes Termination and Contexts concepts to manage calls and 
define call states 

• Allows transactions that consist of several actions and 
commands 

• Provides high availability in the event of equipment or network 
failures 

• Utilizes easy-to-use tools to support the events, signals, and 
statistics necessary to control and manage the Media Gateway 
(MG) 
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Network Assessment 


Voice over Internet Protocol 
Technologies 
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Network Availability 


• Dependent on availability of a redundant network 

- Redundant devices 
-Resilient networking protocols 
-Multiple physical connections 

- Backup power sources 
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Voice Compression 



• Amount of bandwidth depends on compression and 
link layer protocol 

• G.711: 64 Kbps - approximately 

• G.729: 8 Kbps - approximately 

G.729 CODEC provides lowest bandwidth 
and near toil voice quality 
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Assess Network Resources 


Network Assessment Tools 


■ Simulate VoIP traffic flow 

■ Assess link utilization 

1 Observe routing protocols 
« Calculate voice quality 

• Identify jitter, one-way delay, and packet loss 

• Generate detailed reports 


• Sniffer Portable or Pro (Sniffer Technologies) 

• NetlQ Chariot (NetlQ Corporation) 

• NetlQ Qcheck (NetlQ Corporation) 

• NetlQ VoIP Assessor (NetlQ Corporation 

• NetAlly (Viola Networks) 

• Multi-Router Traffic Grapher (Swiss Federal 
Institution) 
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NetAlly 


• Emulates network traffic (as deployed or as planned) 


• Analyzes results and generates reports at scheduled 
times or on demand 


• Primary measurements used are delay, loss, jitter, 
and throughput 

• Consists of Test Center and Traffic Agents 

- Enables you to rapidly isolate sources of network 
performance issues, from the server to end-user desktop 

• Provides flexibility to verify test results by repeating 
identical tests, as needed 
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Multi Router Traffic Grapher 



• SNMP tool that monitors traffic load on network links 
in real-time and displays results on HTML page 

• As pre-deployment tool, can determine router and 
link utilization in WAN environment 

• Collects statistics on any device that has SNMP 
agent 

• Gathers statistics for day, week, month, and year, 
without necessity of onsite engineer 
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Network Improvements 



• Replace or upgrade existing hardware 
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• Implement QoS 

• Negotiate new SLAs 
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